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

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<mailto: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<mailto: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<mailto:sfc@ietf.org>>; sfc-chairs@ietf.org<mailto: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<mailto: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<mailto:i-d-announce@ietf.org>>
Cc: <sfc@ietf.org<mailto: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<mailto: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.