Subject: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt

From: [email-masked]
Date: Tue, 25 May 2021 06:50:54 -0700

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
                          Bhumip Khasnabish
                          Cui Wang
	Filename        : draft-ietf-sfc-multi-layer-oam-11.txt
	Pages           : 24
	Date            : 2021-05-25

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) 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-11.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-multi-layer-oam-11

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Wed, 26 May 2021 06:30:19 +0000

Hi Greg, 

Thank you for taking care of most of the comments. This version is much better. 

I see that no changes were made to show how the requirements in Section 3 are met with the proposed solution. I'm sure you have good reasons for that. 

Also, I have one clarification question about the following: 

(1)
   The sender of the Echo Request MAY use TLVs to
   request that the corresponding Echo Reply is transmitted over the
   specified path.

(2)

   *  Reply via Specified Path (TBA8) value to enforce the use of the
      particular return path specified in the included TLV to verify bi-
      directional continuity and also increase the robustness of the
      monitoring by selecting a more stable path.

I fail to see which TLVs will be used to specify the "return path". Did I missed something? 

Thank you for your efforts.

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de internet-
> [email-masked]
> Envoyé : mardi 25 mai 2021 15:51
> À : [email-masked]
> Cc : [email-masked]
> Objet : [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt
> 
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> 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.

---

From: <[email-masked]>
Date: Fri, 28 May 2021 11:44:48 +0800 (CST)

Hi Med,

many thanks for your help improving this document. I greatly appreciate your thoughtful and detailed comments. Please find my notes in-lined below under the GIM>> tag. I've atteched the working version and diff to highlight the proposed updates.

Regards,

Greg Mirsky

Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division

E: [email-masked] 
www.zte.com.cn

Original Mail

Sender: [email-masked]
To: Greg Mirsky;
CC: [email-masked];
Date: 2021/05/26 00:09
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt

Hi Greg,  

GIM>> I just missed it. Would adding the new text below to the first paragraph of Section 5 be acceptable:

NEW TEXT:

  The SFC NSH Echo Request/Reply defined in this document

   addresses several requirements listed in Section 3.  Specifically, as

   defined in this specification, it can be used to check the continuity

   of an SFP, trace an SFP, localize the failure of the SFP.

(1)

GIM>> I propose adding informational reference to draft-ao-sfc-oam-return-path-specified as follows:

NEW TEXT:

 [I-D.ao-sfc-oam-return-path-specified] provides an
 example of a TLV that can be used to specify the path of the Echo
 Reply.
(2)

GIM>> And here also can refer to draft-ao-sfc-oam-return-path-specified as follows:

NEW TEXT:

      [I-D.ao-sfc-oam-return-path-specified] provides an example of

      defining a specific path for the Echo Reply.

Cheers,
Med

---

From: <[email-masked]>
Date: Fri, 28 May 2021 06:38:07 +0000

Hi Greg,

Please see inline.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de [email-masked]
Envoyé : vendredi 28 mai 2021 05:45
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
Cc : [email-masked]; [email-masked]
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt

Hi Med,

Regards,

Greg Mirsky

Sr. Standardization Expert
Original Mail
Sender: [email-masked]<mailto:[email-masked]>
To: Greg Mirsky;
CC: [email-masked]<mailto:[email-masked]>;
Date: 2021/05/26 00:09
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt
Hi Greg,

NEW TEXT:

[Med] Works for me. Thanks.

(1)

   specified path.

[Med] I would prefer to have the content of ao-sfc-oam-return-path-specified included in draft-ietf-sfc-multi-layer-oam unless you are confident to progress that I-D separately. It is up to you.

NEW TEXT:

   Reply.

(2)

NEW TEXT:

[Med]  Apologies for the late comment but when thinking about this part:
   To trace a particular RSP, the sender may use NSH MD Type 2 Flow ID
   TLV [I-D.ietf-sfc-nsh-tlv<https://datatracker.ietf.org/doc/html/draft-ietf-sfc-multi-layer-oam-11#ref-I-D.ietf-sfc-nsh-tlv>].  The value of the Flow ID field of the
   SFP Echo Request packet MUST be set to the same value as of the
   monitored flow.

I failed to see how flow-id can be help for tracing (list if SFs that were involve in an SFP). Having a list of IP addresses is not sufficient as we need the identity of the SFs that were involved. The registry in draft-ietf-bess-nsh-bgp-control-plane-18#section-10.5 would be useful for this. If you can clarify that part in the text, that would be great. Thank you.

---

From: <[email-masked]>
Date: Sat, 29 May 2021 07:38:34 +0800 (CST)

Hi Med,

thank you the expedient response, Please find my follow-up notes in-lined below tagged GIM2>>.

Regards,

Greg Mirsky

Original Mail

Sender: [email-masked]
To: gregory mirsky10211915;
CC: [email-masked];[email-masked];
Date: 2021/05/27 23:38
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt

Hi Greg,

Please see inline.

Cheers,

Med

 

Hi Med,

Regards,

Greg Mirsky

To: Greg Mirsky;

CC: [email-masked];

Date: 2021/05/26 00:09

Hi Greg,  

NEW TEXT:

 (1)

   specified path.

GIM2>> Thank you for the suggestion. I see the rationale merging the substantive part of draft-ao-sfc-oam-return-path-specified in ths document. I hope the WG Chairs share their thoughts on the best way forward. I'll split the question into a separate thread.

NEW TEXT:

   [I-D.ao-sfc-oam-return-path-specified] provides an    example of a TLV that can be used to specify the path of the Echo    Reply. 

 (2)

 

NEW TEXT:

   TLV [I-D.ietf-sfc-nsh-tlv].  The value of the Flow ID field of the

   monitored flow.

 GIM2>> I much appreciate your comments and questions. I agree with you, Flow-id alone would not reflect SFs. I've updated the text adding the reference to draft-ao-sfc-oam-path-consistency. Mechanism described in that draft allows the collection of the SF Type information as specified

in the Service Function Type registry defined in draft-ietf-bess-nsh-bgp-control-plane.

NEW TEXT:

   TLV [I-D.ietf-sfc-nsh-tlv] in combination with the method described

   in [I-D.ao-sfc-oam-path-consistency].  The value of the Flow ID field

   of the SFP Echo Request packet MUST be set to the same value as of

   the monitored flow.

In Section 3.3 draft-ao-sfc-oam-path-consistency:

  SF Type: Two octets long field.  It is defined in

   [I-D.ietf-bess-nsh-bgp-control-plane] and indicates the type of SF,

   e.g., Firewall, Deep Packet Inspection, WAN optimization controller,

   etc.

What are your thoughts?

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

---

From: <[email-masked]>
Date: Mon, 31 May 2021 07:27:53 +0000

Hi Greg,

Citing ao-sfc-oam-path-consistency is OK for the missing part about recording crossed SFs. However, I don’t see why flow-id is needed as the marking is done at the NSH level.

Thank you.

Cheers,
Med

De : [email-masked] [mailto:[email-masked]]
Envoyé : samedi 29 mai 2021 01:39
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
Cc : [email-masked]; [email-masked]
Objet : Re:[sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt

Hi Med,

Regards,

Greg Mirsky

   the monitored flow.

   etc.

---

From: <[email-masked]>
Date: Tue, 1 Jun 2021 12:27:25 +0800 (CST)

Hi Med,

my understanding of Section 4.5 in draft-ietf-sfc-nsh-tlv is that like the IPv6 Flow Label or the MPLS Entropy label, Flow ID can be used to balance flows across a multipath data plane. I assume that not only SFs of the same type can be connected to a given SFF, but that a lookup for the next SFF may result in more than one destination. If that is the case, and the monitored flow in the service function chain uses particular Flow ID, active OAM must use the same value. 

I much appreciate your thoughts whether my understanding and assumptions hold the water.

Regards,

Greg Mirsky

Original Mail

Sender: [email-masked]
To: gregory mirsky10211915;
CC: [email-masked];[email-masked];
Date: 2021/05/31 00:28
Subject: RE: Re:[sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt

Hi Greg,

 

Thank you.

Cheers,

Med

 

Hi Med,

Regards,

Greg Mirsky

   monitored flow.

NEW TEXT:

   the monitored flow.

   etc.

---

From: <[email-masked]>
Date: Tue, 1 Jun 2021 06:35:44 +0000

Hi Greg,

I suggest the following as the use of flow id is deployment-specific:

OLD:
   the sender may use NSH MD Type 2 Flow ID
   TLV [I-D.ietf-sfc-nsh-tlv<https://datatracker.ietf.org/doc/html/draft-ietf-sfc-multi-layer-oam-11#ref-I-D.ietf-sfc-nsh-tlv>].  The value of the Flow ID field of the
   SFP Echo Request packet MUST be set to the same value as of the
   monitored flow.

NEW:

   If dedicated means (e.g., IPv6 Flow Label [RFC6437],

   Flow ID [I-D.ietf-sfc-nsh-tlv]) are used for distributing

   load across Equal Cost Multi-Path (ECMP) or Link
   Aggregation Group (LAG) paths, these means MAY also be
   used for the SFC OAM traffic. Doing so is meant to control
   whether the SFC Echo Request follows the same RSP as the
   monitored flow.

Please note that this is a “MAY” as the Echo Request can be used to achieve REQ#7 as well (i.e., discover any available path).

BTW, please change “SFP Echo Request” to “SFC Echo Request” in Section 5.7 (many occurrences).

Cheers,
Med

De : [email-masked] [mailto:[email-masked]]
Envoyé : mardi 1 juin 2021 06:27
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [email-masked]; [email-masked]
Objet : Re:[sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt

Hi Med,

my understanding of Section 4.5<https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-tlv#section-4.5> in draft-ietf-sfc-nsh-tlv is that like the IPv6 Flow Label or the MPLS Entropy label, Flow ID can be used to balance flows across a multipath data plane. I assume that not only SFs of the same type can be connected to a given SFF, but that a lookup for the next SFF may result in more than one destination. If that is the case, and the monitored flow in the service function chain uses particular Flow ID, active OAM must use the same value.

Regards,

Greg Mirsky

E: [email-masked]<mailto:[email-masked]>
www.zte.com.cn<http://www.zte.com.cn/>

Original Mail
Sender: [email-masked]<mailto:[email-masked]>
To: gregory mirsky10211915;
CC: [email-masked];[email-masked]<mailto:[email-masked];[email-masked]>;
Date: 2021/05/31 00:28
Subject: RE: Re:[sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt
Hi Greg,

Thank you.

Cheers,
Med

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Envoyé : samedi 29 mai 2021 01:39
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]<mailto:[email-masked]>>
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re:[sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt

Hi Med,

Regards,

Greg Mirsky

   the monitored flow.

   etc.