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

[[e-mail]]

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]<mailto:[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.


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.

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



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



* 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]<mailto:[e-mail]>> De la part de Joel Halpern
> Envoyé : jeudi 2 juin 2022 20:51
> À : [e-mail]<mailto:[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]<mailto:[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]<mailto:[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.