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" ?
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. Would now all of the v-service vendors need to support both ways of encoding service/function IDs ? Isn't this waist of everyone's time and effort ? Last - how does draft-farrel-mpls-sfc works in only IPv6 IP networks ? Oh maybe there is and not going to be such thing ? 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 > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
