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

[[e-mail]]

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
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
E: [e-mail]
www.zte.com.cn
------------------Original Mail------------------
Sender: [e-mail]
To: gregory mirsky10211915;
CC: [e-mail];[e-mail];
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:[e-mail]] De la part de [e-mail]
Envoyé : mercredi 9 juin 2021 18:47
À : [e-mail]
Cc : [e-mail]; BOUCADAIR Mohamed INNOV/NET <[e-mail]>om>; [e-mail]
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: [e-mail]
www.zte.com.cn
Original Mail
Sender: gregory mirsky10211915
To: [e-mail];
CC: [e-mail];[e-mail];
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: [e-mail]
www.zte.com.cn
------------------Original Mail------------------
Sender: [e-mail]
To: gregory mirsky10211915;
CC: [e-mail];[e-mail];
Date: 2021/06/07 00:14
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt
_______________________________________________
sfc mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sfc
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
De : sfc [mailto:[e-mail]] De la part de [e-mail]
Envoyé : lundi 7 juin 2021 04:37
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : [e-mail]; [e-mail]
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
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
E: [e-mail]
www.zte.com.cn
Original Mail
Sender: [e-mail]
To: gregory mirsky10211915;
CC: [e-mail];[e-mail];
Date: 2021/06/02 06:00
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt
_______________________________________________
sfc mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sfc
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:[e-mail]]  De la part de  [e-mail]
Envoyé : mercredi 2 juin 2021 14:56
À :  [e-mail]
Cc :  [e-mail]; [e-mail]
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt
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
_________________________________________________________________________________________________________________________  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.