I have the same observation as Robert here. The IETF has focussed on using NSH as a mechanism for service chaining in SFC WG. We finally see some implementations coming alive. With this proposal we will start from scratch as all SFF and SF implementations will have to be modified. NSH was and still is a hard journey to lineup all implementations. draft-farrel-mpls-sfc is an alternative way to encode the same information of NSH in an MPLS friendly manner. Why do we need this and what’s wrong with NSH is the question we should ask first before considering to adopt this work.
I would advocate the need to define a way in MPLS and SR/SPRING to transport NSH, but we don’t have to reencode NSH in another encapsulation. Just use it as is. From: spring <spring-boun...@ietf.org> on behalf of Robert Raszuk <rob...@raszuk.net> Date: Tuesday, 13 March 2018 at 22:51 To: John E Drake <jdr...@juniper.net> Cc: mpls <m...@ietf.org>, SPRING WG List <spring@ietf.org>, "s...@ietf.org" <s...@ietf.org>, James N Guichard <james.n.guich...@huawei.com>, "adr...@olddog.co.uk" <adr...@olddog.co.uk>, "Francois Clad (fclad)" <fc...@cisco.com> Subject: Re: [spring] [mpls] [sfc] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued" Hi John, However, early adopters were concerned about the availability of hardware NSH implementations and asked us to include the option of using an MPLS label stack to carry the [SPI, SI], which we did. Are you saying that there is more service function hardware out there in the market which support MPLS [SPI,SI] encoding then those supporting NSH ? If so and if you or someone will list and compare both I am game to progress this work - no issue. If not I really do not see much point. So far I have seen zero of the former and quite a bit of the latter hence my post. Yours, Robert. On Tue, Mar 13, 2018 at 10:44 PM, John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>> wrote: Robert, Comments inline. Yours Irrespectively, John From: rras...@gmail.com<mailto:rras...@gmail.com> [mailto:rras...@gmail.com<mailto:rras...@gmail.com>] On Behalf Of Robert Raszuk Sent: Tuesday, March 13, 2018 5:13 PM To: John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>> Cc: James N Guichard <james.n.guich...@huawei.com<mailto:james.n.guich...@huawei.com>>; Francois Clad (fclad) <fc...@cisco.com<mailto:fc...@cisco.com>>; adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>; s...@ietf.org<mailto:s...@ietf.org> Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued" Hi John, There is one point which I am missing in this discussion ... why we are over and over duplicating ways to solve the same problem. Is there some sort of starvation of the problems to be solved ? Or is there an issue of "technology not invented here must be bad" ? [JD] ‘BGP Control Plane for NSH SFC ‘ ( https://tools.ietf.org/html/draft-ietf-bess-nsh-bgp-control-plane-02), the control plane companion to the subject draft is, as its title indicates, designed to work using the NSH. However, early adopters were concerned about the availability of hardware NSH implementations and asked us to include the option of using an MPLS label stack to carry the [SPI, SI], which we did. You admit that draft-farrel-mpls-sfc is an alternative to use of NSH when "to handle situations in which the NSH is not ubiquitously deployed." What are those situations considering that MPLS requires IP both control plane and forwarding to be in place so does NSH. [JD] See above Would now all of the v-service vendors need to support both ways of encoding service/function IDs ? [JD] I would expect a graceful transition, i.e., one SFF at a time, from MPLS label stack to NSH, and the control plane draft explicitly includes the infrastructure necessary to allow both to be included, on a hop by hop basis, in the same service function path (the instantiation of a service function chain.) Isn't this waist of everyone's time and effort ? [JD] See above Last - how does draft-farrel-mpls-sfc works in only IPv6 IP networks ? Oh maybe there is and not going to be such thing ? [JD] Like a charm. The underlay would be IPv6, perhaps w/ SR, and the overlay would be NSH. We use the Encapsulation attribute to completely decouple the overlay and underlay networks. Best, Robert. On Tue, Mar 13, 2018 at 9:59 PM, John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>> wrote: Jim, Excellent point. We thought a context label was crucial in order to achieve scalability (2**40) bits. A single 20 bit globally unique SFI identifier didn’t seem to be practical to us. Yours Irrespectively, John From: mpls [mailto:mpls-boun...@ietf.org<mailto:mpls-boun...@ietf.org>] On Behalf Of James N Guichard Sent: Tuesday, March 13, 2018 3:00 PM To: Francois Clad (fclad) <fc...@cisco.com<mailto:fc...@cisco.com>>; adr...@olddog.co.uk<mailto:adr...@olddog.co.uk> Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>; s...@ietf.org<mailto:s...@ietf.org> Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued" Hi Francois, One comment below .. From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Francois Clad (fclad) Sent: Tuesday, March 13, 2018 2:27 PM To: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk> Cc: mpls <m...@ietf.org<mailto:m...@ietf.org>>; SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>; s...@ietf.org<mailto:s...@ietf.org> Subject: Re: [mpls] [sfc] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued" Hi Adrian, On 9 Mar 2018, at 10:17, Adrian Farrel <adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>> wrote: I, too, hope we can move to a technical discussion of the differences between the proposals The issue is that, from a technical point of view, there is no difference between section 6 (MPLS Segment Routing) of your draft-farrel-mpls-sfc and the solution that was originally documented in draft-xu-mpls-service-chaining, as Xiaohu pointed out several times. Jim> as far as I can tell this is not exactly true.. draft-xu-mpls-service-chaining-00 talks about using an MPLS label to identify a service segment. Draft-farrel-mpls-sfc talks about using 2 labels, an SFC context label and an SF label, to essentially mimic NSH behavior. The authors of that draft even go as far as to say (about the context label) “.. using the semantics of the SPI is exactly as defined in [RFC8300]” which is exactly what you state you don’t want to do in draft-xuclad-spring-sr-service-chaining. Therefore I am not sure how you can come to the conclusion that there is no difference between the two solutions. Jim Considering that draft-xu-mpls-service-chaining was submitted almost one year before draft-farrel-mpls-sfc, the MPLS Segment Routing approach described in section 6 of draft-farrel-mpls-sfc belongs in draft-xu-mpls-service-chaining, which is now draft-xuclad-spring-sr-service-chaining. To be fair to draft-xu-mpls-service-chaining, I believe that draft-farrel-mpls-sfc should be re-spinned without section 6 before continuing towards WG adoption. Thanks, Francois and not spend time thrashing around in IETF politics. I'm sure the ADs will help us understand what is written in the various WG charters, so our best next step would be to read (you know, like all the words :-) what is in the drafts. However, since Zafar ascribes to me something that I did not say and that is not recorded in the minutes, perhaps I can set that straight. He said... > From IETF process viewpoint, this call for adaption is like putting the "cart > ahead of the horse." > MPLS WG comes last in the process after there is an agreement from Spring and > SFC groups > on the need for MPLS data plane changes proposed by the draft. I raised this > point at the mic > at SFC WG meeting at IETF100 and Adrian agreed to it. I.e., MPLS WG comes at > the last stage > in the process; expert to review this work does not sit in the MPLS WG. According to the minutes, Zafar said... | Zafar Ali: before defining the solution, is this the right approach in SFC? Starting | in MPLS WG is wrong thing to do. And I responded... | Adrian: This was already presented in SFC WG today. In the SFC WG I said... | - The draft discusses how MPLS can be used for SFC. It is being discussed in the | MPLS working group. | - We are looking at environments in which deployed MPLS routers can be used | for creating an SFC, rather than using NSH. If you want my opinion: - The SFC WG is chartered to work on NSH only - The MPLS WG is chartered to work on MPLS - This draft asks for MPLS code points so can only be in MPLS - This draft must be reviewed in SFC and SPRING as it progresses and certainly at WG last call Adrian From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Zafar Ali (zali) Sent: 09 March 2018 00:02 To: Francois Clad (fclad); 徐小虎(义先) Cc: mpls; SPRING WG List; s...@ietf.org<mailto:s...@ietf.org>; draft-farrel-mpls-sfc; mpls-chairs; mpls Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued" Importance: High Dear MPLS WG Chairs and the authors of draft-farrel-mpls-sfc, I would like to draw your attention to the serious issue raised by Xiaohu and Francois. Summary: Please note that this working group adaption against the IETF process and its spirit. Please recall the adaption call. Details: Just to reiterate the issue raised by Xiaohu and Francois. At last IETF we discussed 3 drafts (draft-xu-mpls-service-chaining-03, draft-farrel-mpls-sfc and draft-clad-spring-segment-routing-service-chaining) in SFC, Spring and MPLS WG. There was the specific conversation on which WG the work belongs, and the assumed follow-up was for the chairs and ADs to have the discussion on home for these drafts. From IETF process viewpoint, this call for adaption is like putting the "cart ahead of the horse." MPLS WG comes last in the process after there is an agreement from Spring and SFC groups on the need for MPLS data plane changes proposed by the draft. I raised this point at the mic at SFC WG meeting at IETF100 and Adrian agreed to it. I.e., MPLS WG comes at the last stage in the process; expert to review this work does not sit in the MPLS WG. The drafts also did not stay dormant after IETF100. There were email conversations among the authors of the concerned drafts (https://mailarchive.ietf.org/arch/msg/mpls/bmH5QH65b2Non2Y7qNEBBI_kSOA<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_mpls_bmH5QH65b2Non2Y7qNEBBI-5FkSOA&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=m-yc8M0wYF1jXzDEPWo3iUnoM43SPOpgJvQIpF6kYHA&e=>). Authors of draft-xu- and draft-clad- followed the proper IETF process, discussed and merged the contents. They published draft-xuclad-spring-sr-service-chaining-01 and asked WG for a "presentation slot" at IETF100. Only to find that draft-farrel-mpls-sfc used a backdoor to force this "WG adaption call"! One also has to question the timing of this adaption call when the WGs are meeting face-to-face in a couple of weeks. Is it no longer IETF spirit to make use of the face-to-face to do the right thing, especially when we are meeting in two weeks? In the light of the above, my request to the authors of draft-farrel and MPLS WG chairs to please do the right thing and recall this WG adaptation call. Thanks Regards ... Zafar From: mpls <mpls-boun...@ietf.org<mailto:mpls-boun...@ietf.org>> on behalf of "Francois Clad (fclad)" <fc...@cisco.com<mailto:fc...@cisco.com>> Date: Thursday, March 8, 2018 at 5:21 AM To: "徐小虎(义先)" <xiaohu....@alibaba-inc.com<mailto:xiaohu....@alibaba-inc.com>> Cc: draft-farrel-mpls-sfc <draft-farrel-mpls-...@ietf.org<mailto:draft-farrel-mpls-...@ietf.org>>, "m...@ietf.org<mailto:m...@ietf.org>" <m...@ietf.org<mailto:m...@ietf.org>>, SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>, mpls-chairs <mpls-cha...@ietf.org<mailto:mpls-cha...@ietf.org>>, mpls <mpls-boun...@ietf.org<mailto:mpls-boun...@ietf.org>> Subject: Re: [mpls] [spring] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued" Hi Xiaohu, all, I agree with the point raised by Xiaohu. The draft-farrel-mpls-sfc is copying ideas described in draft-xu-mpls-service-chaining. Please note that the work in draft-xu-mpls-service-chaining started one year before draft-farrel-mpls-sfc. At IETF100, three drafts in this area were discussed / presented: - draft-xu-mpls-service-chaining - draft-farrel-mpls-sfc - draft-clad-spring-segment-routing-service-chaining There was discussion over the mic on the right home for these drafts among SFC, SPRING and MPLS, but no consensus was reached. As Xiaohu mentioned, draft-xu-mpls-service-chaining and draft-clad-spring-segment-routing-service-chaining have later merged as draft-xuclad-spring-sr-service-chaining. We have also requested a slot for presenting this draft during the upcoming IETF meeting. In this context, we believe that asking for WG adoption for one of these drafts is premature. Thanks, Francois On 7 Mar 2018, at 01:13, 徐小虎(义先) <xiaohu....@alibaba-inc.com<mailto:xiaohu....@alibaba-inc.com>> wrote: Hi all, As I had pointed out at the last IETF meeting, section 6 of this draft has an serious overlap with https://tools.ietf.org/html/draft-xu-mpls-service-chaining-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxu-2Dmpls-2Dservice-2Dchaining-2D03&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=UckZMQ6j33_dO8XnGXbarFxtcuHJrGDIsg2aAdG-sOk&e=> that has now been updated by https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxuclad-2Dspring-2Dsr-2Dservice-2Dchaining-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=EgLaNYJSlDEdK7n2o1EWQsLRHCJBnTmZM-HtaMLsMLc&e=> with a merge with draft-clad-spring-segment-routing-service-chaining. Hence, I'm very interesting to know the intention of such rewritting of a given mechanism that has been described in another draft. Is there any special nutrition? Best regards, Xiaohu ------------------------------------------------------------------ 发件人：IETF Secretariat <ietf-secretariat-re...@ietf.org<mailto:ietf-secretariat-re...@ietf.org>> 发送时间：2018年3月6日(星期二) 22:09 收件人：draft-farrel-mpls-sfc <draft-farrel-mpls-...@ietf.org<mailto:draft-farrel-mpls-...@ietf.org>>; mpls <m...@ietf.org<mailto:m...@ietf.org>>; mpls-chairs <mpls-cha...@ietf.org<mailto:mpls-cha...@ietf.org>> 主 题：[mpls] The MPLS WG has placed draft-farrel-mpls-sfc in state "Call For Adoption By WG Issued" The MPLS WG has placed draft-farrel-mpls-sfc in state Call For Adoption By WG Issued (entered by Loa Andersson) The document is available at https://datatracker.ietf.org/doc/draft-farrel-mpls-sfc/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dfarrel-2Dmpls-2Dsfc_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=eOBxho8eESw8vj3hUU0WF6BoW3Zu1CCi69KJRsBTt6k&e=> _______________________________________________ mpls mailing list m...@ietf.org<mailto:m...@ietf.org> https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=Vy6H7zgumIaKzJb84UmsKCxcUsJYtXS_xqbcFgxdc3c&e=> _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=_74fpq8zHtLUzCRwAD_Doy3iW0OdJ5032fZhJGPgr-w&e=> _______________________________________________ sfc mailing list s...@ietf.org<mailto:s...@ietf.org> https://www.ietf.org/mailman/listinfo/sfc<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sfc&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=W-fAjn4fh4q8os5gZIZl0A2Lu0GPoS7MgJoN7yGeCG4&s=nWWylOI0JVmT-t3N9mWaEFezzrqU6NxfM3FrKE3G0Pk&e=> _______________________________________________ mpls mailing list m...@ietf.org<mailto:m...@ietf.org> https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=aIvAamM2MsrmNIsMiGG4DnY2vL9aBbhe-npduXgbqKA&s=U5Y-B-3Uwb_RpxLQVNUkQuqxv7ONpkRA_8Z22R_fD1I&e=>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
