+1 to adopt both. Although the label stack is similar between draft-farrel section6 and draft-xuclad, but other points are different, e.g., meta data. If we consider a solution with several separate technical points, the two drafts do collapse in some points. But if you consider a solution as an integral one, the two drafts are different.
BR Lizhong > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Apr 2018 10:55:55 -0400 > From: "Andrew G. Malis" <[email protected]> > To: "Zafar Ali (zali)" <[email protected]> > Cc: "[email protected]" <[email protected]>, SPRING WG List <[email protected]>, > "[email protected]" <[email protected]>, mpls <[email protected]> > Subject: Re: [mpls] [sfc] Working Group adoption of > draft-farrel-mpls-sfc > Message-ID: > <CAA=duU0BWK9tik2FXvj_wqMbfMwp5XmU6ADNXE52bpetMXdczw > @mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Zafar, et al, > > Perhaps the fairest to all concerned is for the MPLS WG to adopt both > drafts, and then it will be up to the WG (rather than the authors) to best > determine the technical details going forward, and how best to document > them. That way the work becomes the consensus product of the WG. > > Cheers, > Andy > > > On Sun, Apr 15, 2018 at 12:44 AM, Zafar Ali (zali) <[email protected]> wrote: > > > Dear Stewart, WG Chairs and the WG, > > > > > > > > I do not agree with Stewart?s points and will response in a separate > > email. But all that is just noise and that cannot resolve the issue at > > hand. > > > > > > > > A countless time, Xiaohu has raised the issue that the intellectual > > property for the contents in section 6 of draft-farrel-mpls-sfc belongs > to > > draft-xu-mpls-service-chaining. Please see one of Xiaohu's recent emails > > with the subject *"[spring] For the fairness and justice of the IETF > > culture"* dated Thursday, April 5, 2018 at 12:34 AM, copied in the > > following. > > > > > > > > This issue was also raised by many during the WG adoption poll of the > > document. The chairs adopted the work with the promise of fixing the > issue. > > Specifically, in the email to announce the adoption of the ID to the WG, > > the chair(s) mentioned the following: > > > > > > > > "That decision is taken, the issues that has been pointed out are > > > > noted. These issues need to be resolved on the mailing list and > > > > rough consensus need to be reached for text changes in the document. > > > > Actually the members of the working group have much more influence on > > > > a working group document, than on an individual draft. > > > > It would be far better if we now focused on proposing text changes, > > > > rather than discussing processes." > > > > > > > > This is a serious issue; we need to remove section 6 from draft- > > farrel-mpls-sfc to move forward. These contents will proceed in > draft-xu*, > > where the contents started initially. Everyone will have a fair chance to > > contribute to the contents as part of collaborations on draft-xu*. > > > > > > > > Thanks > > > > > > > > Regards ? Zafar > > > > > > > > *From: *spring <[email protected]> on behalf of "???(??)" < > > [email protected]> > > *Date: *Thursday, April 5, 2018 at 12:34 AM > > *To: *"[email protected]" <[email protected]>, SPRING WG List <[email protected]> > > *Cc: *"[email protected]" <[email protected]> > > *Subject: *[spring] For the fairness and justice of the IETF culture//Re: > > [mpls] What to do with draft-ietf-mpls-sfc-00.txt > > > > > > > > Hi all, > > > > > > > > As I had pointed out before, this draft describes two MPLS-based SFC > > > > approaches: one is how to encode the NSH info, more specifically, the SPI > > > > and SI info by two MPLS labels, which is still a stateful SFC mechanism > > > > just like NSH; another is how to leverage the MPLS-SR to realize a > > > > stateless SFC (see section 6). > > > > > > > > It has been pointed out by many people that section 6 of the draft copies > > > > the > > > > idea of (https://tools.ietf.org/html/draft-xu-mpls-service-chaining) > > > > without any technology contribution except replacing ?MPLS Segment > > > > Routing? by ?Label Stack?. Funnily, one author of draft-ietf-mpls-sfc > > > > had inadvertently admitted > > > > "using a different name for the same thing is not so clever" (see > > > > https://mailarchive.ietf.org/arch/msg/mpls/y7FTc38ysVf6PyJlA04MEFSN9nc) > in > > > > another thread. > > > > > > > > IMHO, the indulgence towards such behavior of copying > > > > ideas of existing drafts with word tricks would seriously trample > > > > underfoot the fairness and justice of the IETF culture. At least, it > would > > > > badly damage the interest and enthusiasm of IETF participants, especially > > > > newcomers and non-native speakers of English. > > > > > > > > Best regards, > > > > Xiaohu > > > > > > > > > > > > > > > > > > > > *From: *mpls <[email protected]> on behalf of Stewart Bryant < > > [email protected]> > > *Date: *Friday, April 13, 2018 at 3:10 AM > > *To: *"???(??)" <[email protected]> > > *Cc: *"[email protected]" <[email protected]>, mpls <[email protected]>, > > Robert Raszuk <[email protected]>, "[email protected]" <[email protected]> > > *Subject: *Re: [mpls] [sfc] Working Group adoption of > > draft-farrel-mpls-sfc > > > > > > > > > > > > > > > > On 13/04/2018 08:23, ???(??) wrote: > > > > Hi Stewart, > > > > > > > > Thanks for your response. For the SR-based SFC mechanism that has been > > described in draft-xuclad*, it's not helpful to describe it again in > > another draft. The most simple and efficient way to address the > > overlapping issue is to reference draft-xuclad* rather than > > "using a different name for the same thing". I'm looking forward to > > seeing the revision of draft-farrel* that would address the overlapping > > issue concretely. > > > > > > Please read what I said. > > > > There are subtle but important technical differences between the two > > approaches. > > > > - Stewart > > > > > > > > > > If co-authors of draft-farrel* believed the current text as described in > > draft-xuclad* is not good enough or misses something important, any > > comments and suggestions are more than welcome. > > > > > > I will send you some text to include in draft-xuclad that points to the > > important differences in the approach taken in draft-farrel. This will > > clarify the issue to the reader. > > > > I hope that this is an acceptable resolution of this issue. > > > > - Stewart > > > > > > > > > > > > Best regards, > > > > Xiaohu > > > > ------------------------------------------------------------------ > > > > Stewart Bryant <[email protected]> <[email protected]> > > > > 2018?4?13?(???) 13:27 > > > > ???(??) <[email protected]> <[email protected]> > > > > mpls <[email protected]> <[email protected]>; "Bernier, Daniel" > > <[email protected]> <[email protected]>; Robert Raszuk > > <[email protected]> <[email protected]>; [email protected] <[email protected]> > > <[email protected]>; [email protected] <[email protected]> <[email protected]> > > > > Re: [mpls] [sfc] Working Group adoption of draft-farrel-mpls-sfc > > > > > > > > Hi Xiaohu > > > > > > > > What an earlier version of the draft said is of no importance. What it > > says going forward is what counts. > > > > > > > > Perhaps the way to address your concern is to include some text of the > > form that I used in my email of yesterday to describe to the reader the > > difference in approach. This is consistent with earlier advice in this > > discussion to reference the work from which this forked. > > > > > > > > - Stewart > > > > > > > > > > > > Sent from my iPad > > > > > > On 13 Apr 2018, at 03:35, ???(??) <[email protected]> wrote: > > > > Hi Stewart, > > > > > > > > If draft-farrel* was just describing an MPLS-based SFC technology that is > > different from the MPLS-SR-based SFC technology that has been described > in > > draft-xuclad*, that would be fine. However, draft-farrel* also described > > the technology that has been described in draft-xuclad* (see section 6) > by > > "using a different name for the same thing". Note that the title of > > section 6 in those pervious versions of draft-farrel* is > > > > "MPLS Segment Routing". One co-author of draft-farrel* said they worked > very hard to change the "Segment Routing" term to "label stack" term in the > new version of draft-farrel* in order to deal with the overlapping issue. > However, such change is just "using a different name for the same thing", > and it doesn't solve the overlapping issue at all, as had been pointed out > by many people. As said by one co-author of draft-farrel*, in a thread > which is irrelavant to this overlapping issue, "using a different name for > the same thing is not so clever:)". In fact, it would cause unneccessary > confusions to implementors by describing the same technology within > different drafts. More badly, it would set a bad precedant in the IETF of > copying the idea of the existing draft by "using a different name for the > same thing". > > > > > > > > Best regards, > > > > Xiaohu > > > > ------------------------------------------------------------------ > > > > Stewart Bryant <[email protected]> > > > > 2018?4?12?(???) 23:04 > > > > "Bernier, Daniel" <[email protected]>; Robert Raszuk < > > [email protected]> > > > > [email protected] <[email protected]>; [email protected] <[email protected]> > > > > Re: [mpls] [sfc] Working Group adoption of draft-farrel-mpls-sfc > > > > > > > > > > Rather than have a process discussion, I think we should go up a level > > and better understand the technical differences between the two drafts. > > > > draft-farrel-mpls-sfc describes the actions at a hop in terms of a tuple > > that mirrors the SFC approach that allows a short indication of > > potentially re-entrant chains. In its simplest form it uses a compact > > MPLS stack to describe an arbitarily complex path that is compatile with > > simple edge routers which are often challenged in terms of the number of > > labels that they can push. > > > > draft-xu-clad-spring-sr-service-chaining unrolls the path and explicitly > > calls out each hop and each function into the label stack. This results > > in a much larger MPLS label stack that will challenge some edge routers. > > The way that we generally deal with imposition limits is through the use > > of binding-SIDs, which in the limiting case resolves to the approach in > > draft-farrel with the limitation that the position on the path is > > implicit in the label stack size rather than explicitly > > specified by the SI. > > > > Mid-flight path changes (if such things are needed) is clearly simpler > > with draft-farrel. > > > > The short stack in draft-farrel comes at the cost of greater network > > forwarding stack, and the long stack is the price that draft-xu-clad > > pays for the reduction in forwarding state. > > > > The optimal design point between forwarding and control plane state is > > something that is dependent on many parameters, and is dependent on many > > network and operational factors, so much so, that don't think it is wise > > to rule either out of scope at this stage. > > > > The hybrid mode in section 6 of draft-farrel supports the mixed mode in > > section 7 of the draft. This allows the construction of SFCs that are > > the concatination of two or more compacted sub-chains. This allows the > > operator to deploy a solution with the advantages of draft-farrel > > together with some of the flexibility of draft-xu-clad. > > > > At this stage the two drafts are sufficienly different that I think we > > need to proceed with both at least to the point where we fully > > understand the detailed consequences of the two approachs and the > > scenarios where each finds it's niche. > > > > After developing a better understanding the detail of each design, their > > control plane, and operational contexts and how each maps to customer > > network requirements, we can move the drafts to the appropriate IETF > > track. Such tracks may be anything from abandonment to IETF standard for > > one or both of these approaches. > > > > Meanwhile I think that we need to focus our efforts on a deeper > > understanding of the technology and how each might make the Internet > > work better, rather than spending effort on arguing about IETF process. > > > > - Stewart > > > > _______________________________________________ > > mpls mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > _______________________________________________ > > mpls mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > > > _______________________________________________ > > mpls mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/mpls > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <https://mailarchive.ietf.org/arch/browse/mpls/attachments/ > 20180415/9a47c611/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > mpls mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/mpls > > > ------------------------------ > > End of mpls Digest, Vol 168, Issue 18 > ************************************* >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
