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

[[e-mail]]

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-----
> De : sfc [mailto:[e-mail]] De la part de
> [e-mail]
> Envoyé : mardi 15 juin 2021 04:27
> À : 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,
> 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.

_________________________________________________________________________________________________________________________

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.