Re: [sfc] WG LC on draft-ietf-sfc-multi-layer-oam

[Greg Mirsky <[e-mail]>]

Hi Med,
thank you for your helpful follow-up. Please find my notes inlined under
the GIM2>> tag. Attached is the new diff to highlight all the updates.

Regards,
Greg

On Mon, Jun 6, 2022 at 10:47 PM <[e-mail]> wrote:

> Hi Greg,
>
>
>
> Thank you for the changes. This looks better, but there are still very few
> points that are unaddressed.
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* sfc <[e-mail]> *De la part de* Greg Mirsky
> *Envoyé :* mardi 7 juin 2022 01:58
> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> *Cc :* [e-mail]
> *Objet :* Re: [sfc] WG LC on draft-ietf-sfc-multi-layer-oam
>
>
>
> Hi Med,
>
> many thanks for your comments. I've prepared an updated version and
> appreciate your feedback. Please find my responses in-lined below tagged
> GIM>>. Attached are the diff and copy of the updated draft.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Fri, Jun 3, 2022 at 2:25 AM <[e-mail]> wrote:
>
> Hi Joel, all,
>
> I reviewed this document several times. It is ready to move forward.
>
> Some easy-to-fix comments are provided below:
>
> * Title:
>
>   OLD: Active OAM for Service Function Chaining
>   NEW: Active OAM for Service Function Chaining (SFC)
>
> GIM>> Done
>
>
> * Section 3: It would be helpful to have a discussion at the end of the
> document how these various requirements listed here are met with the
> proposed solution. Alternatively, REQ# can be called out in subsequent
> sections to tag where it is addressed. For example, this text can be
> updated to refer the REQ#
>
>    The
>    SFC Echo Request/Reply defined in this document addresses several
>    requirements listed in Section 3.  Specifically, it can be used to
>    check the continuity of an SFP, trace an SFP, or localize the failure
>    within an SFP.
>
> GIM>> I propose this update to the text above
>
> NEW TEXT:
>
> The
>
>    SFC Echo Request/Reply defined in this document conforms to REQ#1
>
>    (Section 3) by using the NSH encapsulation of the monitored service.
>
>    Further, the mechanism addresses requirements REQ#2 through REQ#7,
>
>    listed in Section 3.  Specifically, it can be used to check the
>
>    continuity of an SFP, trace an SFP, or localize the failure within an
>
>    SFP.  Also, note that REQ#8 can be addressed by an extension of the
>
>    SFC Echo Request/Reply described in this document adding proxy
>
>    capability.
>
>
>
> *[Med] This is great. However, a similar text is still needed for REQ#3,
> 4, 5, and 6.*
>
GIM2>> I propose this form:
    Further, the mechanism addresses requirements *REQ#2 through REQ#7*,
    listed in Section 3.
or listing them all:
    Further, the mechanism addresses requirements REQ#2, REQ#3, REQ#4,
    REQ#5, REQ#6, and REQ#7 listed in Section 3.
Which form is acceptable?

>
>
>
> Similar text can be considered for other REQ#s.
>
> *  Section 4: s/The O bit in NSH/The O bit in the NSH
>
> GIM>> Done
>
>
> * Section 6.1: Check the list of errors is update to date. The values are
> not aligned with ones in Table 8.
>
> GIM>> Thank you for catching this miss-merge. Fixed.
>
>
> * Section 6.3: Please check the list of allowed codes. Shouldn’t these
> values be aligned with the content on Table 7?
>
> GIM>> Indeed, thank you for pointing this out. Extended the list with
> references to RFC 9145.
>
> *[Med] Thanks. *
>
>
>
>
> * Please consider some text about MTU. this can be basically echoing what
> is already in 8300 or Section 8 of rfc9145
>
> * Section 6.6.3: Move 9015 to be listed as Normative given that it is
> required for:
>
> GIM>> Done
>
> *[Med] This one is still listed as informative. Please fix it. Thanks.*
>
GIM2>> Thank you for catching that. I've moved to the Normative RFC 9145.
Done (and verified) RFC 9015.

>
>       SF Type - two-octet field.  It is defined in [RFC9015] and
>       indicates the type of SF, e.g., Firewall, Deep Packet Inspection,
>       WAN optimization controller, etc.
>
> * Section 10.1:
>
> (1)
>
> OLD:
>    IANA is requested to assign a new type from the SFC Next Protocol
>    registry as follows:
>
> NEW:
>    IANA is requested to assign a new type from the "NSH Next Protocol"
>    registry available at <
> https://www.iana.org/assignments/nsh/nsh.xhtml#next-protocol>:
>
> GIM>> I am not used to this form. Can the decision be left for the RFC
> Editor and IANA Action?
>
> *[Med] The point is to have the required information as per the following
> (excerpt from the writeup):*
>
>
>
> *==*
>
> *Confirm that any referenced IANA registries have been clearly identified.*
>
> *==*
>
GIM2>> Thank you for pointing that out to me. I propose the updated text as
follows:
IANA is requested to assign a new type from the sub-registry SFC Next
Protocol of the Network Service Header (NSH) Parameters registry as follows:
Would that be acceptable?

>
>
>
>
>
> (2) Consider adding a note for the RFC editor to update all TBA1
> occurrences with the assigned value.
>
> GIM>> In my experience, an RFC Editor and IANA Action always take care of
> these updates.
>
>
>
> *[Med] It is very likely and they usually ask a question to confirm this.
> The point is to be explicit about the intent (omissions may happen).*
>
GIM2>> Understood. I propose the following text after Table 2:
[RFC Editor, please update all occurrences of TBA1 with the value assigned
by IANA Action.]

>
>
>
>
> * Sections 10.2.1, 10.3.2, 10.3.3, 10.3.4, 10.4, and 10.5:
>
> OLD: IETF Consensus
> NEW: IETF Review
>
> GIM>> Thank you! Done.
>
>
> * Sections 10.2.1, 10.3.2, 10.3.3, 10.4, and 10.5:
>
> Any particular reason why some values are reserved? (see the example below)
>
>       | 0             |           Reserved          | This document |
>
> While these values are used for other registries, e.g., Section 10.3.4.
>
> * Section 10.3.4:
>
> GIM>> In part that is the historical use of Error Code in Echo
> Request/Reply with zero value indicating No Error.
>
>
>
>
> OLD:
>    | 255     |             Reserved            |               |
>
> NEW:
>    | 255     |             Reserved            | This document |
>
> GIM>> Done
>
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : sfc <[e-mail]> De la part de Joel Halpern
> > Envoyé : jeudi 2 juin 2022 20:51
> > À : [e-mail]
> > Objet : [sfc] WG LC on draft-ietf-sfc-multi-layer-oam
> >
> > Technically, the draft is still in last call from quite some time
> > ago.
> >
> > For clarity, and as there have been clarifications in relate
> > terminology, the chairs have decided to consider taht we are
> > restarting the last call today.
> >
> > This Working Group Last call will run for 2 weeks (and a day)
> > until CoB on June 17, 2022.
> >
> > Please respond positively or negatively to this call.  Note that
> > if we do not get enough responses we will likely be unable to
> > advance the document before the WG closes.
> >
> > When responding, please provide clear motivation either for or
> > against publication as an RFC.  Substantive comments are MUCH more
> > helpful than "yes" or "no".
> >
> >
> > Thank you,
> >
> > Joel and Jim
> >
> > _______________________________________________
> > sfc mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sfc
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>