Re: [Last-Call] [Int-dir] Intdir telechat review of draft-ietf-sfc-oam-framework-13

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thank you Carlos for your review.

I used your review to ballot on the document for the 7th of May IESG telechat except for the reference to BCP 14 in an informational document (and usually architecture documents are indeed informational).

Best regards

-éric

-----Original Message-----
From: Int-dir <int-dir-bounces@xxxxxxxx> on behalf of Carlos Bernardos via Datatracker <noreply@xxxxxxxx>
Reply-To: Carlos Bernardos <cjbc@xxxxxxxxxx>
Date: Monday, 4 May 2020 at 14:30
To: "int-dir@xxxxxxxx" <int-dir@xxxxxxxx>
Cc: "last-call@xxxxxxxx" <last-call@xxxxxxxx>, "sfc@xxxxxxxx" <sfc@xxxxxxxx>, "draft-ietf-sfc-oam-framework.all@xxxxxxxx" <draft-ietf-sfc-oam-framework.all@xxxxxxxx>
Subject: [Int-dir] Intdir telechat review of draft-ietf-sfc-oam-framework-13

    Reviewer: Carlos Bernardos
    Review result: Ready with Nits

    Thanks a lot for this document. I liked reading it.

    I have a first generic comment, minor but that I still wanted to make. Section
    2 is about SFC Layering Model, which to me seems like an introduction, but not
    really specifically related to the core topic of the draft. Do we need that
    section in this draft? Maybe it can be condensed and included as a first part
    of section 3.

    The document has a big component of requirements and gap analysis, which brings
    one question: should the document use normative RFC 2199 language when
    expressing the requirements? In Section 3.2.1 t is used, for example, but not
    in other parts. I think some work is needed to make this consistent.

    I think that the following sentence needs to be reworded: "In order to apply
    such OAM functions at the service layer, they need to be enhanced to operate a
    single SF/SFF to multiple SFs/SFFs in an SFC and also in multiple SFCs."

    I think the behaviour of SFC-aware nodes that do not support a given OAM
    operation should be better explained. For example, the sentence "When an SF
    supports OAM functionality, it is desirable to process the packet and provide
    an appropriate response to allow end-to-end verification." might be to vague.

    Table 4 has a small formatting issue in the Classifier row.

    I think some in-band vs out-band OAM discussion would be interesting to add to
    the document.


    _______________________________________________
    Int-dir mailing list
    Int-dir@xxxxxxxx
    https://www.ietf.org/mailman/listinfo/int-dir

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux