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

[Greg Mirsky <[e-mail]>]

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.

>
> 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.

>
> * 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

>
>       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?

>
> (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.

>
>
> * 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
>