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

Hi Med,
thank you for your quick response. I've modified the text according to your
suggestions and uploaded the new version.

Regards,
Greg

On Fri, Oct 15, 2021 at 9:57 AM <mohamed.boucadair@orange.com> wrote:

> Hi Greg,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Greg Mirsky <gregimirsky@gmail.com>
> *Envoyé :* vendredi 15 octobre 2021 18:06
> *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
> *Cc :* Service Function Chaining IETF list <sfc@ietf.org>;
> sfc-chairs@ietf.org
> *Objet :* 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.
>
>
>
> *[Med] I would just delete “over an IP network” from the NEW text. Thanks.
> *
>
>
>
>
>
> 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.
>
>
>
> *[Med] This is better, thanks. *
>
>
>
> (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?
>
> *[Med] Yes… but I would just maintain the one in the Security
> Considerations Section.  *
>
>
>
> 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.
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>