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

[[e-mail]]

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


[cid:image001.gif@01D75DC9.267E73B0]

[cid:image002.gif@01D75DC9.267E73B0]
E: [e-mail]<mailto:[e-mail]>
www.zte.com.cn<http://www.zte.com.cn/>

Original Mail
Sender: gregory mirsky10211915
To: [e-mail]<mailto:[e-mail]>;
CC: [e-mail];[e-mail]<mailto:[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]<mailto:[e-mail]>
www.zte.com.cn<http://www.zte.com.cn>
------------------Original Mail------------------
Sender: [e-mail]<mailto:[e-mail]>
To: gregory mirsky10211915;
CC: [e-mail];[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
Envoyé : lundi 7 juin 2021 04:37
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>
www.zte.com.cn<http://www.zte.com.cn>
Original Mail
Sender: [e-mail]<mailto:[e-mail]>
To: gregory mirsky10211915;
CC: [e-mail];[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
Envoyé : mercredi 2 juin 2021 14:56
À :  [e-mail]<mailto:[e-mail]>
Cc :  [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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.