Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt
gregory.mirsky@ztetx.com Wed, 09 June 2021 16:47 UTC
Return-Path: <gregory.mirsky@ztetx.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2B13A1E50 for <sfc@ietfa.amsl.com>; Wed, 9 Jun 2021 09:47:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.873
X-Spam-Level:
X-Spam-Status: No, score=-0.873 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, OBFU_TEXT_ATTACH=1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_HTML_ATTACH=0.01, T_OBFU_HTML_ATTACH=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRcGBIIWSLhZ for <sfc@ietfa.amsl.com>; Wed, 9 Jun 2021 09:47:36 -0700 (PDT)
Received: from mxus.zteusa.com (mxus.zteusa.com [4.14.134.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B3E3A1E4C for <sfc@ietf.org>; Wed, 9 Jun 2021 09:47:35 -0700 (PDT)
Received: from mse-us.zte.com.cn (unknown [10.36.11.29]) by Forcepoint Email with ESMTPS id 81BBE7AE73B7FB0878D1; Thu, 10 Jun 2021 00:47:22 +0800 (CST)
Received: from mgapp01.zte.com.cn ([10.36.9.142]) by mse-us.zte.com.cn with SMTP id 159GlCPh018569; Thu, 10 Jun 2021 00:47:12 +0800 (GMT-8) (envelope-from gregory.mirsky@ztetx.com)
Received: from mapi (mgapp01[null]) by mapi (Zmail) with MAPI id mid81; Thu, 10 Jun 2021 00:47:12 +0800 (CST)
Date: Thu, 10 Jun 2021 00:47:12 +0800
X-Zmail-TransId: 2af960c0f0905350f02b
X-Mailer: Zmail v1.0
Message-ID: <202106100047121714116@zte.com.cn>
In-Reply-To: <202106080846554451804@zte.com.cn>
References: 162195065398.30344.3488434826066371346@ietfa.amsl.com, 202105290738343893700@zte.com.cn, 21809_1622446074_60B48FFA_21809_385_1_787AE7BB302AE849A7480A190F8B933035394D6E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup, 202106011227255525275@zte.com.cn, 30026_1622529345_60B5D541_30026_164_1_787AE7BB302AE849A7480A190F8B933035395504@OPEXCAUBMA2.corporate.adroot.infra.ftgroup, 202106020502330776158@zte.com.cn, 30757_1622638586_60B77FFA_30757_170_1_787AE7BB302AE849A7480A190F8B933035396372@OPEXCAUBMA2.corporate.adroot.infra.ftgroup, 3646_1622638782_60B780BE_3646_355_2_787AE7BB302AE849A7480A190F8B9330353963A4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup, 202106071037222520529@zte.com.cn, 4500_1623050060_60BDC74C_4500_107_11_787AE7BB302AE849A7480A190F8B933035399695@OPEXCAUBMA2.corporate.adroot.infra.ftgroup, 202106080846554451804@zte.com.cn
Mime-Version: 1.0
From: gregory.mirsky@ztetx.com
To: gregory.mirsky@ztetx.com
Cc: mohamed.boucadair@orange.com, gregimirsky@gmail.com, sfc@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-us.zte.com.cn 159GlCPh018569
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/-mI7T4rJFjHAkJaR44Vh8OICxjc>
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jun 2021 16:47:43 -0000
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: gregory.mirsky@ztetx.com www.zte.com.cn Original Mail Sender: gregory mirsky10211915 To: mohamed.boucadair@orange.com; CC: gregimirsky@gmail.com;sfc@ietf.org; 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: gregory.mirsky@ztetx.com www.zte.com.cn ------------------Original Mail------------------ Sender: mohamed.boucadair@orange.com To: gregory mirsky10211915; CC: gregimirsky@gmail.com;sfc@ietf.org; Date: 2021/06/07 00:14 Subject: Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt _______________________________________________ sfc mailing list sfc@ietf.org 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:sfc-bounces@ietf.org] De la part de gregory.mirsky@ztetx.com Envoyé : lundi 7 juin 2021 04:37 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com> Cc : gregimirsky@gmail.com; sfc@ietf.org 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: gregory.mirsky@ztetx.com www.zte.com.cn Original Mail Sender: mohamed.boucadair@orange.com To: gregory mirsky10211915; CC: gregimirsky@gmail.com;sfc@ietf.org; Date: 2021/06/02 06:00 Subject: Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt _______________________________________________ sfc mailing list sfc@ietf.org 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:sfc-bounces@ietf.org] De la part de mohamed.boucadair@orange.com Envoyé : mercredi 2 juin 2021 14:56 À : gregory.mirsky@ztetx.com Cc : gregimirsky@gmail.com; sfc@ietf.org 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 De : sfc [mailto:sfc-bounces@ietf.org] De la part de gregory.mirsky@ztetx.com Envoyé : mardi 1 juin 2021 23:03 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com> Cc : gregimirsky@gmail.com; sfc@ietf.org Objet : Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt 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: gregory.mirsky@ztetx.com www.zte.com.cn Original Mail Sender: mohamed.boucadair@orange.com To: gregory mirsky10211915; CC: gregimirsky@gmail.com;sfc@ietf.org; Date: 2021/05/31 23:36 Subject: Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt _______________________________________________ sfc mailing list sfc@ietf.org 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 : gregory.mirsky@ztetx.com [mailto:gregory.mirsky@ztetx.com] Envoyé : mardi 1 juin 2021 06:27 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com> Cc : gregimirsky@gmail.com; sfc@ietf.org 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: gregory.mirsky@ztetx.com www.zte.com.cn Original Mail Sender: mohamed.boucadair@orange.com To: gregory mirsky10211915; CC: gregimirsky@gmail.com;sfc@ietf.org; 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 : gregory.mirsky@ztetx.com [mailto:gregory.mirsky@ztetx.com] Envoyé : samedi 29 mai 2021 01:39 À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com> Cc : gregimirsky@gmail.com; sfc@ietf.org 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. _________________________________________________________________________________________________________________________ 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. _________________________________________________________________________________________________________________________ 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. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc
- [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-… internet-drafts
- Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-… mohamed.boucadair
- Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-… gregory.mirsky
- Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-… mohamed.boucadair
- Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-… gregory.mirsky
- Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-… mohamed.boucadair
- Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-… gregory.mirsky
- Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-… mohamed.boucadair
- Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-… gregory.mirsky
- Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-… mohamed.boucadair
- Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-… mohamed.boucadair
- Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-… gregory.mirsky
- Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-… mohamed.boucadair
- Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-… gregory.mirsky
- Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-… gregory.mirsky
- Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-… mohamed.boucadair
- Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-… gregory.mirsky
- Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-… mohamed.boucadair
- Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-… gregory.mirsky