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> wrote: > Robert, > > > > Comments inline. > > > > Yours Irrespectively, > > > > John > > > > *From:* 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> > *Cc:* James N Guichard <james.n.guich...@huawei.com>; Francois Clad > (fclad) <fc...@cisco.com>; adr...@olddog.co.uk; mpls <m...@ietf.org>; > SPRING WG List <spring@ietf.org>; 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 > <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> 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] *On Behalf Of *James N > Guichard > *Sent:* Tuesday, March 13, 2018 3:00 PM > *To:* Francois Clad (fclad) <fc...@cisco.com>; adr...@olddog.co.uk > > > *Cc:* mpls <m...@ietf.org>; SPRING WG List <spring@ietf.org>; 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 <mpls-boun...@ietf.org>] *On > Behalf Of *Francois Clad (fclad) > *Sent:* Tuesday, March 13, 2018 2:27 PM > *To:* adr...@olddog.co.uk > *Cc:* mpls <m...@ietf.org>; SPRING WG List <spring@ietf.org>; 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> 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 <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; 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> on behalf of "Francois Clad (fclad)" > <fc...@cisco.com> > *Date: *Thursday, March 8, 2018 at 5:21 AM > *To: *"徐小虎(义先)" <xiaohu....@alibaba-inc.com> > *Cc: *draft-farrel-mpls-sfc <draft-farrel-mpls-...@ietf.org>, " > m...@ietf.org" <m...@ietf.org>, SPRING WG List <spring@ietf.org>, > mpls-chairs <mpls-cha...@ietf.org>, mpls <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> 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> > > 发送时间：2018年3月6日(星期二) 22:09 > > 收件人：draft-farrel-mpls-sfc <draft-farrel-mpls-...@ietf.org>; mpls < > m...@ietf.org>; mpls-chairs <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 > 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 > 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 > 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 > 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
