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

From: <[email-masked]>
Date: Wed, 2 Jun 2021 05:02:33 +0800 (CST)

Hi Med,

thank you for the suggested text. I've updated the working version (it is attached and the diff too).

Please take a look at your convenience and share your thoughts on it.

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: gregory mirsky10211915;
CC: [email-masked];[email-masked];
Date: 2021/05/31 23:36
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

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

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: 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,

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,

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

Regards,

Greg Mirsky

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

 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:

  To trace a particular RSP, the sender may use NSH MD Type 2 Flow ID

   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.

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

---

From: <[email-masked]>
Date: Wed, 2 Jun 2021 12:56:25 +0000

Hi Greg,

Thank you for sharing this updated version.

Rather than just reviewing the diff, I took the liberty to review the full text to check the internal consistency of the changes since -07. There are some few pending issues, comments, and edits that you can find at:

·         doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-sfc-multi-layer-oam-07-rev%20Med.doc

·         pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-sfc-multi-layer-oam-12-rev%20Med.pdf

Please let me know if any clarification is needed from my side.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mardi 1 juin 2021 23:03
À : 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,

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 23:36
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc
Hi Greg,

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.

Cheers,
Med

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Envoyé : mardi 1 juin 2021 06:27
À : BOUCADAIR Mohamed INNOV/NET <[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,

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

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

   the monitored flow.

   etc.

_________________________________________________________________________________________________________________________

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: Wed, 2 Jun 2021 12:59:41 +0000

Re-,

The doc version to use is this one: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-sfc-multi-layer-oam-12-rev%20Med.docx (the pdf one is correct).

Apologies for the inconvenience.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mercredi 2 juin 2021 14:56
À : [email-masked]
Cc : [email-masked]; [email-masked]
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt

Hi Greg,

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de [email-masked]<mailto:[email-masked]>

Hi Med,

Regards,

Greg Mirsky

Original Mail

OLD:

NEW:

Cheers,
Med

Hi Med,

Regards,

Greg Mirsky

Original Mail

Thank you.

Cheers,
Med

Hi Med,

Regards,

Greg Mirsky

   the monitored flow.

   etc.

Thank you.

---

From: <[email-masked]>
Date: Mon, 7 Jun 2021 10:37:22 +0800 (CST)

Hi Med,

thank you for the comments and proposed updates. I'm working with them to update the draft. If I understood them correctly, several changes you've suggested are to set the scope of the proposed solution onto SFC NSH, not SFC in general. I think that is an interesting idea, but as it changes the scope of the WG document, I think we need to discuss it with the group. I'd note that the scope of RFC 8924 appears to analyze OAM for all possible realizations of SFC with a more detailed discussion of NSH encapsulation. In draft-ietf-sfc-multi-layer-oam, we've followed a similar approach making SFC Echo Request/Reply generic for SFC and defining its applicability in the case of SFC NSH encapsulation.

Regards,

Greg Mirsky

Original Mail

Date: 2021/06/02 06:00

Re-,

 

 

Cheers,

Med

 

Hi Greg,

 

 

 

Cheers,

Med

 

Hi Med,

Regards,

Greg Mirsky

 

Original Mail

Date: 2021/05/31 23:36

Hi Greg,

 

OLD:

   monitored flow.

NEW:

   monitored flow.

 

 

Cheers,

Med

 

Hi Med,

Regards,

Greg Mirsky

 

Original Mail

Date: 2021/05/31 00:28

Hi Greg,

 

Thank you.

Cheers,

Med

 

Hi Med,

Regards,

Greg Mirsky

   monitored flow.

NEW TEXT:

   the monitored flow.

   etc.

---

From: <[email-masked]>
Date: Mon, 7 Jun 2021 07:14:19 +0000

Hi Greg,

The section requirements can be maintained generic but the other ones updating the O bit and the ones about messages are specific to NSH. No?

That’s said, that’s not the part that concerns me when reviewing the full text. What I do think requires more focus is captured by the comments in Section 5 and its subsections.

When those are fixes (and the decision to merge or not the other TLVs), I think that the document will be ready for the WGLC. Hope to see that SOON.

Cheers,
Med

Envoyé : lundi 7 juin 2021 04:37

Hi Med,

Regards,

Greg Mirsky

Original Mail

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : mercredi 2 juin 2021 14:56
À : [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 Greg,

•         doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-sfc-multi-layer-oam-07-rev%20Med.doc

•         pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-sfc-multi-layer-oam-12-rev%20Med.pdf

Cheers,
Med

Hi Med,

Regards,

Greg Mirsky

Original Mail

OLD:

NEW:

Cheers,
Med

Hi Med,

Regards,

Greg Mirsky

Original Mail

Thank you.

Cheers,
Med

Hi Med,

Regards,

Greg Mirsky

   the monitored flow.

   etc.

Thank you.

---

From: <[email-masked]>
Date: Tue, 8 Jun 2021 08:46:55 +0800 (CST)

Hi Med,
thank you for the clarification. I will concentrate on addressing your comments to Section 5, including its sub-sections.
I hope to hear more from the WG regarding the possible import of substantive parts of draft-ao-sfc-return-path-specified and draft-ao-sfc-path-consistency that define valuable extensions to the SFC Echo Request/Reply protocol.

Regards,
Greg Mirsky
------------------Original Mail------------------
Sender: [email-masked]
To: gregory mirsky10211915;
CC: [email-masked];[email-masked];
Date: 2021/06/07 00:14
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt

Hi Greg,

---

From: <[email-masked]>
Date: Thu, 10 Jun 2021 00:47:12 +0800 (CST)

Hi Med,

I've updated the draft and added several notes, mostly in Section 5. Please, find the new working version, diff, and the copy with your comments and my notes attached.

I am looking forward to hear your thoughts on the updates and the state of the document.

Your contribution to this work is outstanding, thank you!

Best regards,

Greg Mirsky

Original Mail

Sender: gregory mirsky10211915
To: [email-masked];
CC: [email-masked];[email-masked];
Date: 2021/06/07 17:47
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt

Hi Med,
 
Regards,
Greg Mirsky
------------------Original Mail------------------
Sender: [email-masked]
To: gregory mirsky10211915;
CC: [email-masked];[email-masked];
Date: 2021/06/07 00:14
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt
 
Hi Greg,

---

From: <[email-masked]>
Date: Thu, 10 Jun 2021 06:02:53 +0000

Hi Greg,

Thank you for taking care of the comments. Please find below some replies and some comments to the NEW text:

(1)

“GIM>> I propose to split the part that updates RFC 8300 and, I agree, is specific to NSH, from the definition of SFC Active OAM Header. Would you agree?”

Med: Works for me. Please consider adding some clarifying text about how the generic part is intended to work independently of NSH.

(2)

“GIM>> I’ve reviewed several RFCs, including RFC 8300, and couldn’t find a request to set IANA registry for the Version field. A new text added in both places. I much appreciate your feedback.”

Med: There is one in RFC8300, actually. It is available here: https://www.iana.org/assignments/nsh/nsh.xhtml#version

(3)

“Which address is used to send this error?
GIM>> Using information in the Source TLV per Section 5.5. Would it help moving the description of the Source TLV to Section 5.3?”

Med: This issue is that this text is a about “If the packet is not well-formed”, which includes the case where the source TLV is not well-formed!

(4)

“Does/how these ones interacts with the flags at the NSH OAM level?
GIM>> SFC Active OAM Flags are intended to define processing and behavior of the Active OAM. Global Flags in the SFC Echo Request define processing of the SFC Echo Request message.”

Med: I interpret the the flag at at the OAM level have no implications on those in the echo level. I would add that clarification to the text. Also, here is what we get for an echo request. The naming is confusing as “global” is used for a specific object, not the parent header.

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V | Msg Type  |     Flags     |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V |        Reserved           |         Global Flags          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       ….

Below some comments about the NEW text in the candidate version:

* For this text:

   Only a single Source ID TLV MAY be present in an SFC Echo Request
   message.  If more than one Source ID TLV is present, the receiver
   MUST use the first TLV and ignore the rest.

The first TLV may not be convenient in case both IPv4 and IPv6 sources are included and the SFC includes a NAT64 and an upstream SF is only reachable using one single AF.

I suggest to restrict to one source per AF + if more one source is included the SF MUST NOT replicate the response but must select one.

* Figure 5: Please fix the misalignment issue.

Please note that we can get rid of the address family field as this can be determined by the length.

* There is still things such as “The SFC NSH Echo Request/Reply …”.

* (nit) Please fix this text:

“The remaining code points are allocated
   according to Table 7: as specified in Table 7. “

Thank you.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mercredi 9 juin 2021 18:47
À : [email-masked]
Cc : [email-masked]; BOUCADAIR Mohamed INNOV/NET <[email-masked]>; [email-masked]
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt

Hi Med,

Best regards,

Greg Mirsky

Original Mail
To: [email-masked]<mailto:[email-masked]>;

Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
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/06/07 00:14
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt

Hi Greg,
www.zte.com.cn<http://www.zte.com.cn>

---

From: <[email-masked]>
Date: Tue, 15 Jun 2021 10:26:42 +0800 (CST)

Hi Med,
I sincerely appreciate your help and the dedication to SFC. Please find my notes in response to your comments in-line below tagged GIM2>>. Attached are the updated working version and its diff to -12.
I hope we're converging on the outstanding issues.

Best regards,
Greg Mirsky
------------------Original Mail------------------
Sender: [email-masked]
To: gregory mirsky10211915;
CC: [email-masked];[email-masked];
Date: 2021/06/09 23:03
Subject: RE: [sfc]  I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt
v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);}" _ue_custom_node_="true">
Hi Greg,
Thank you for taking care of the comments. Please find below some replies and some comments to the NEW text:
(1)
“GIM>> I propose to split the part that updates RFC 8300 and, I agree, is specific to NSH, from the definition of SFC Active OAM Header. Would you agree?”
Med: Works for me. Please consider adding some clarifying text about how the generic part is intended to work independently of NSH.
GIM2>> Thank you for the suggestion. I propose the following update in the Introduction section:
NEW TEXT:
SFC Echo Request and Echo Reply, defined in 
this document, can be used with encapsulations other than NSH, for
example, using MPLS encapsulation, as described in [RFC8595]. The
applicability of the SFC Echo Request/Reply mechanism in SF
encapsulations other than NSH is outside the scope of this document.
(2)
“GIM>> I’ve reviewed several RFCs, including RFC 8300, and couldn’t find a request to set IANA registry for the Version field. A new text added in  both places. I much appreciate your feedback.”
Med: There is one in RFC8300, actually. It is available here: https://www.iana.org/assignments/nsh/nsh.xhtml#version
GIM2>> I've clearly missed that, thank you. I've addred two sub-sections to the IANA Considerations. Would you agree with Sections 9.2.1 and 9.3.1?
(3)
“Which address is used to send this error?
GIM>> Using information in the Source TLV per Section 5.5. Would it help moving the description of the Source TLV to Section 5.3?”
Med: This issue is that this text is a about “If the packet is not well-formed”, which includes the case where the source TLV is not well-formed!
GIM2>> Thank you for pointing this out for me. I agree, the processing of the received Echo Request message must be changed. Here's the updated text of the paragraph:
NEWTEXT:
Firstly, if the SFC Echo Request is authenticated, the receiving SFF
first MUST verify the authentication.  Then the receiver SFF MUST
validate the Source TLV, as defined in Section 6.3.1.  If the
authentication validation has failed and the Source TLV is considered
properly formatted, the SFF MUST send to the system identified in the
Source TLV (see Section 6.5), according to a rate-limit control
mechanism, an SFC Echo Reply with the Return Code set to
"Authentication failed" and the Subcode set to zero.  If the Source
TLV is determined malformed, the received SFC Echo Request processing
is stopped, the message is dropped, and the event SHOULD be logged,
according to a rate-limiting control for logging.  
(4)
“Does/how these ones interacts with the flags at the NSH OAM level?
GIM>> SFC Active OAM Flags are intended to define processing and behavior of the Active OAM. Global Flags in the SFC Echo Request define processing  of the SFC Echo Request message.”
Med: I interpret the the flag at at the OAM level have no implications on those in the echo level. I would add that clarification to the text. Also, here is what we get for an echo  request. The naming is confusing as “global” is used for a specific object, not the parent header.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | Msg Type  |     Flags     |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |        Reserved           |         Global Flags          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GIM2>> Thank you for the suggested text. I've changed the name of the field in the Echo Request/Reply message from "Global Flags" to "Echo Request Flags" and updated the description of the field as follows:
The Echo Request Flags is a two-octet bit vector field.  Note that
a flag defined in the Flags field of the SFC Active OAM header in
Figure 2 has no implication of those defined in the Echo Request
Flags field of an Echo Request/Reply message.
….
Below some comments about the NEW text in the candidate version:
* For this text:
Only a single Source ID TLV MAY be present in an SFC Echo Request
message.  If more than one Source ID TLV is present, the receiver
MUST use the first TLV and ignore the rest.
The first TLV may not be convenient in case both IPv4 and IPv6 sources are included and the SFC includes a NAT64 and an upstream SF is only reachable using one single AF.
I suggest to restrict to one source per AF + if more one source is included the SF MUST NOT replicate the response but must select one.
GIM2>> I agree your proposal, thank you. The updated text now reads as the following:
A single Source ID TLV for each address family, i.e., IPv4 and IPv6,
MAY be present in an SFC Echo Request message.  If the Source TLVs
for both address families are present in an SFC Echo Request message,
the SFF MUST NOT replicate an SFC Echo Reply but choose the
destination IP address for the SFC Echo Reply based on the local
policy.  If more than one Source ID TLV per the address family is
present, the receiver MUST use the first TLV and ignore the rest.
* Figure 5: Please fix the misalignment issue.
Please note that we can get rid of the address family field as this can be determined by the length.
GIM2>> Sorry for my sloppiness. I agree, the address family can be implied from the value of the Length field. Beow is the updated text:
Length is a two-octets-long field, and the value equals the length
of the Value field in octets.  The value of the Length field can
be 8 or 20.  If the value of the field is neither, the Source TLV
is considered to be malformed.
* There is still things such as “The SFC NSH Echo Request/Reply …”.
GIM2>> Got it and removed all.
* (nit) Please fix this text:
“The remaining code points are allocated
according to Table 7: as specified in Table 7. “
GIM2>> Ouch, cleared.
Thank you.
Cheers,
Med
De : sfc [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mercredi 9 juin 2021 18:47
À : [email-masked]
Cc : [email-masked]; BOUCADAIR Mohamed INNOV/NET <[email-masked]>; [email-masked]
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt
Hi Med,
I've updated the draft and added several notes, mostly in Section 5. Please, find the new working version, diff, and the copy with your comments and my notes attached.
I am looking forward to hear your thoughts on the updates and the state of the document.
Your contribution to this work is outstanding, thank you!
Best 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: gregory mirsky10211915
To: [email-masked];
CC: [email-masked];[email-masked];
Date: 2021/06/07 17:47
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt
Hi Med,
thank you for the clarification. I will concentrate on addressing your comments to Section 5, including its sub-sections.
I hope to hear more from the WG regarding the possible import of substantive parts of draft-ao-sfc-return-path-specified and draft-ao-sfc-path-consistency that define valuable extensions to the SFC Echo Request/Reply protocol.
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

---

From: <[email-masked]>
Date: Tue, 15 Jun 2021 06:34:51 +0000

Hi Greg, 

Except some very few nits, this version looks good to me. Thank you.

Feel free to consider or ignore them.

== Clarification

Section 6.3.1: Given that source TLV includes both IP address and port number, I suggest to make this change:

OLD:
   Because the NSH does not identify the ingress node that
   generated the Echo Request, the source ID MUST be included in the
   message and used as the IP destination address for IP/UDP
   encapsulation of the SFC Echo Reply.

NEW:
   Because the NSH does not identify the ingress node that
   generated the Echo Request, the source ID MUST be included in the
   message and used as the IP destination IP address and destination
   port number of the SFC Echo Reply.

=== nits 

(1) Section 6.4:

OLD: 
   Firstly, if the SFC Echo Request is authenticated, the receiving SFF
   first MUST verify the authentication.

NEW:
   If the SFC Echo Request is integrity-protected, the receiving SFF
   first MUST verify the authentication.

(2) Section 6.6:

OLD: 
  An SFF SHOULD NOT accept SFC Echo Reply unless the received passes ...

NEW:
  An SFF SHOULD NOT accept SFC Echo Reply unless the received message 
  passes ...

(3) Section 9.3.4: 

OLD:
   specified in [RFC8126].  The remaining code points are allocated
   according to Table 11: as specified in Table 11.

NEW:
   specified in [RFC8126].  The remaining code points are allocated
   according to Table 11.

Cheers,
Med

> -----Message d'origine-----
> Envoyé : mardi 15 juin 2021 04:27
> I sincerely appreciate your help and the dedication to SFC. Please
> find my notes in response to your comments in-line below tagged
> GIM2>>. Attached are the updated working version and its diff to -
> 12.
> 预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline
> Product R&D Institute/Wireline Product Operation Division
> v\:* {behavior:url(#default#VML);} o\:*
> {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);}
> .shape {behavior:url(#default#VML);}" _ue_custom_node_="true"> Hi
> Greg, Thank you for taking care of the comments. Please find below
> some replies and some comments to the NEW text:
> (1)
> “GIM>> I propose to split the part that updates RFC 8300 and, I
> agree, is specific to NSH, from the definition of SFC Active OAM
> Header. Would you agree?”
> Med: Works for me. Please consider adding some clarifying text about
> how the generic part is intended to work independently of NSH.
> SFC Echo Request and Echo Reply, defined in this document, can be
> used with encapsulations other than NSH, for example, using MPLS
> encapsulation, as described in [RFC8595]. The applicability of the
> SFC Echo Request/Reply mechanism in SF encapsulations other than NSH
> is outside the scope of this document.
> (2)
> “GIM>> I’ve reviewed several RFCs, including RFC 8300, and couldn’t
> find a request to set IANA registry for the Version field. A new
> text added in  both places. I much appreciate your feedback.”
> Med: There is one in RFC8300, actually. It is available here:
> https://www.iana.org/assignments/nsh/nsh.xhtml#version
> GIM2>> I've clearly missed that, thank you. I've addred two sub-
> sections to the IANA Considerations. Would you agree with Sections
> 9.2.1 and 9.3.1?
> (3)
> GIM>> Using information in the Source TLV per Section 5.5. Would it
> help moving the description of the Source TLV to Section 5.3?”
> Med: This issue is that this text is a about “If the packet is not
> well-formed”, which includes the case where the source TLV is not
> well-formed!
> GIM2>> Thank you for pointing this out for me. I agree, the
> processing of the received Echo Request message must be changed.
> Here's the updated text of the paragraph:
> NEWTEXT:
> authentication validation has failed and the Source TLV is
> considered properly formatted, the SFF MUST send to the system
> identified in the Source TLV (see Section 6.5), according to a rate-
> limit control mechanism, an SFC Echo Reply with the Return Code set
> to "Authentication failed" and the Subcode set to zero.  If the
> Source TLV is determined malformed, the received SFC Echo Request
> processing is stopped, the message is dropped, and the event SHOULD
> be logged, according to a rate-limiting control for logging.
> (4)
> GIM>> SFC Active OAM Flags are intended to define processing and
> behavior of the Active OAM. Global Flags in the SFC Echo Request
> define processing  of the SFC Echo Request message.”
> Med: I interpret the the flag at at the OAM level have no
> implications on those in the echo level. I would add that
> clarification to the text. Also, here is what we get for an echo
> request. The naming is confusing as “global” is used for a specific
> object, not the parent header.
> GIM2>> Thank you for the suggested text. I've changed the name of
> the field in the Echo Request/Reply message from "Global Flags" to
> "Echo Request Flags" and updated the description of the field as
> follows:
> The Echo Request Flags is a two-octet bit vector field.  Note that a
> flag defined in the Flags field of the SFC Active OAM header in
> The first TLV may not be convenient in case both IPv4 and IPv6
> sources are included and the SFC includes a NAT64 and an upstream SF
> is only reachable using one single AF.
> I suggest to restrict to one source per AF + if more one source is
> included the SF MUST NOT replicate the response but must select one.
> for both address families are present in an SFC Echo Request
> message, the SFF MUST NOT replicate an SFC Echo Reply but choose the
> GIM2>> Sorry for my sloppiness. I agree, the address family can be
> implied from the value of the Length field. Beow is the updated
> text:
> of the Value field in octets.  The value of the Length field can be
> 8 or 20.  If the value of the field is neither, the Source TLV is
> considered to be malformed.
> “The remaining code points are allocated according to Table 7: as
> specified in Table 7. “
> GIM2>> Ouch, cleared.
> Thank you.
> Cheers,
> Med
> De : sfc [mailto:[email-masked]] De la part de
> [email-masked] Envoyé : mercredi 9 juin 2021 18:47 À :
> [email-masked] Cc : [email-masked]; BOUCADAIR
> Mohamed INNOV/NET <[email-masked]>; [email-masked] Objet
> : Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt
> Hi Med,
> I've updated the draft and added several notes, mostly in Section 5.
> Please, find the new working version, diff, and the copy with your
> comments and my notes attached.
> 预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline
> Product R&D Institute/Wireline Product Operation Division
> thank you for the clarification. I will concentrate on addressing
> your comments to Section 5, including its sub-sections.
> I hope to hear more from the WG regarding the possible import of
> substantive parts of draft-ao-sfc-return-path-specified and draft-
> ao-sfc-path-consistency that define valuable extensions to the SFC
> Echo Request/Reply protocol.
> Regards,
> Greg Mirsky
> 预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline
> Product R&D Institute/Wireline Product Operation Division
> The section requirements can be maintained generic but the other
> ones updating the O bit and the ones about messages are specific to
> NSH. No?
> That’s said, that’s not the part that concerns me when reviewing the
> full text. What I do think requires more focus is captured by the
> comments in Section 5 and its subsections.
> When those are fixes (and the decision to merge or not the other
> TLVs), I think that the document will be ready for the WGLC. Hope to
> see that SOON.
> Cheers,
> Med
> De : sfc [mailto:[email-masked]] De la part de
> [email-masked] Envoyé : lundi 7 juin 2021 04:37 À :
> 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,
> thank you for the comments and proposed updates. I'm working with
> them to update the draft. If I understood them correctly, several
> changes you've suggested are to set the scope of the proposed
> solution onto SFC NSH, not SFC in general. I think that is an
> interesting idea, but as it changes the scope of the WG document, I
> think we need to discuss it with the group. I'd note that the scope
> of RFC 8924 appears to analyze OAM for all possible realizations of
> SFC with a more detailed discussion of NSH encapsulation.  In draft-
> ietf-sfc-multi-layer-oam, we've followed a similar approach making
> SFC Echo Request/Reply generic for SFC and defining its
> applicability in the case of SFC NSH encapsulation.
> Regards,
> Greg Mirsky
> 预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline
> Product R&D Institute/Wireline Product Operation Division
> The doc version to use is this one:
> https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-
> ietf-sfc-multi-layer-oam-12-rev%20Med.docx (the pdf one is correct).
> De :  sfc [mailto:[email-masked]]  De la part de
> [email-masked] Envoyé : mercredi 2 juin 2021 14:56 À :
> [email-masked] Cc :  [email-masked]; [email-masked]
> Rather than just reviewing the diff, I took the liberty to review
> the full text to check the internal consistency of the  changes
> since -07. There are some few pending issues, comments, and edits
> that you can find at:
> ·         doc:  https://github.com/boucadair/IETF-Drafts-
> Reviews/raw/master/draft-ietf-sfc-multi-layer-oam-07-rev%20Med.doc
> ·         pdf:  https://github.com/boucadair/IETF-Drafts-
> Reviews/blob/master/draft-ietf-sfc-multi-layer-oam-12-rev%20Med.pdf
> ____________________________________________________________________
> _____________________________________________________  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: Thu, 17 Jun 2021 03:06:56 +0800 (CST)

Hi Med,

thank you for your comments and help making this document ready for the WGLC.

I accept all updates you've kindly suggested. I will upload the new version later today.

Best regards,

Greg Mirsky

Original Mail

Date: 2021/06/14 23:35

Hi Greg,  

 
== Clarification

OLD:
 
NEW:
 
=== nits  
 
(1) Section 6.4:
 
OLD:  
 
NEW:
 
(2) Section 6.6:
 
OLD:  
 
NEW:
 
(3) Section 9.3.4:  
 
OLD:
 
NEW:
 
Cheers,
Med
 
> [email-masked]