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

[[e-mail]]

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)

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

Similar text can be considered for other REQ#s.

*  Section 4: s/The O bit in NSH/The O bit in the NSH

* Section 6.1: Check the list of errors is update to date. The values are not aligned with ones in Table 8.

* Section 6.3: Please check the list of allowed codes. Shouldn’t these values be aligned with the content on Table 7?

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

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

(2) Consider adding a note for the RFC editor to update all TBA1 occurrences with the assigned value. 

* Sections 10.2.1, 10.3.2, 10.3.3, 10.3.4, 10.4, and 10.5:
	
OLD: IETF Consensus
NEW: IETF Review

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

OLD:
   | 255     |             Reserved            |               |

NEW:
   | 255     |             Reserved            | This document |

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.