Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-layer-oam-14.txt

Hi Med,
thank you for your review and comments. Please find my notes in-lined below
tagged by GIM>>.

Regards,
Greg

On Wed, Oct 13, 2021 at 7:54 AM <mohamed.boucadair@orange.com> wrote:

> Hi Greg, all,
>
>
>
> Please find below some quick comments about this version:
>
>
>
> (1)
>
>
>
> “While SFC Echo Request always traverses the SFP, it is directed to,
>
> the corresponding Echo Reply usually is sent over an IP network.”
>
>
>
> I’m not sure to get the intent here, especially that an SFP is still “over
> an IP network”.
>
GIM>> We are pointing out that the Echo Request traverses SFP using NSH
while the Echo Reply is not. Do you think that explicitly referring to the
role of NSH helps to make it clearer:
OLD TEXT:
   While SFC Echo Request always traverses the SFP, it is directed to,
   the corresponding Echo Reply usually is sent over an IP network.
NEW TEXT:
   While SFC Echo Request always traverses the SFP, it is directed to,
   using NSH, the corresponding Echo Reply usually is sent over an IP
   network without NSH.

>
>
> I have the same concern with this one:
>
>
>
> “There are scenarios when it is beneficial to direct the responder to
>
> use a path other than the IP network“
>
GIM>> Would the following update make it clearer:
OLD TEXT:
   There are scenarios when it is beneficial to direct the responder to
   use a path other than the IP network.
NEW TEXT:
   In some cases, an operator might choose to direct the responder
   to send the Echo Reply with NSH over a particular SFP.

>
>
> (2) You may want align these two statements to avoid what may be perceived
> as an internal inconsistency (or redundant requirements):
>
>
>
>       The Message Authentication Code (MAC) Context Header that is
> defined
>
>       in [I-D.ietf-sfc-nsh-integrity] MAY be used to protect the SFC
> Echo
>
>       Request's integrity when using the SFC Return Path TLV
>
>
>
> vs.
>
>
>
>       When the integrity protection for SFC active OAM, and SFC Echo
>
>       Request/Reply in particular, is required, it is RECOMMENDED to use
>
>       one of the Context Headers defined in [I-D.ietf-sfc-nsh-integrity].
>
GIM>> Thank you for catching this inconsistency. Would you agree that
s/MAY/SHOULD/ resolves it?

>
>
> Cheers,
>
> Med
>
>
>
> *De :* sfc <sfc-bounces@ietf.org> *De la part de* Greg Mirsky
> *Envoyé :* vendredi 8 octobre 2021 18:19
> *À :* Service Function Chaining IETF list <sfc@ietf.org>;
> sfc-chairs@ietf.org
> *Objet :* [sfc] Fwd: I-D Action: draft-ietf-sfc-multi-layer-oam-14.txt
>
>
>
> Dear All,
>
> following the discussion on the SFC WG mailing list and the direction from
> the SFC WG Chairs, we've merged substantive parts
> of draft-ao-sfc-oam-path-consistency
> and draft-ao-sfc-oam-return-path-specified with this draft where the base
> functionality of the SFC NSH Echo Request/Reply is defined. The authors
> greatly appreciate and welcome your comments, questions, and suggestions.
> We're looking forward to the discussion that will help to progress this
> document to the WG LC.
>
>
>
> Regards,
>
> Greg (on behalf of the authors).
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Fri, Oct 8, 2021 at 9:13 AM
> Subject: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-14.txt
> To: <i-d-announce@ietf.org>
> Cc: <sfc@ietf.org>
>
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Service Function Chaining WG of the IETF.
>
>         Title           : Active OAM for Service Function Chaining
>         Authors         : Greg Mirsky
>                           Wei Meng
>                           Ting Ao
>                           Kent Leung
>                           Gyan Mishra
>         Filename        : draft-ietf-sfc-multi-layer-oam-14.txt
>         Pages           : 37
>         Date            : 2021-10-08
>
> Abstract:
>    A set of requirements for active Operation, Administration, and
>    Maintenance (OAM) of Service Function Chains (SFCs) in a network is
>    presented in this document.  Based on these requirements, an
>    encapsulation of active OAM messages in SFC and a mechanism to detect
>    and localize defects are described.
>
>    This document updates RFC 8300.  Particularly, it updates the
>    definition of O (OAM) bit in the Network Service Header (NSH) (RFC
>    8300) and defines how an active OAM message is identified in the NSH.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sfc-multi-layer-oam/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-sfc-multi-layer-oam-14.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-multi-layer-oam-14
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> 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.
>
>