Re: [mpls] [sfc] Working Group adoption of draft-farrel-mpls-sfc

[Lizhong Jin <[e-mail]>]

+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" <[e-mail]>
> To: "Zafar Ali (zali)" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, SPRING WG List <[e-mail]>,
>         "[e-mail]" <[e-mail]>, mpls <[e-mail]>
> 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) <[e-mail]> 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 <[e-mail]> on behalf of "???(??)" <
> > [e-mail]>
> > *Date: *Thursday, April 5, 2018 at 12:34 AM
> > *To: *"[e-mail]" <[e-mail]>, SPRING WG List <[e-mail]>
> > *Cc: *"[e-mail]" <[e-mail]>
> > *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 <[e-mail]> on behalf of Stewart Bryant <
> > [e-mail]>
> > *Date: *Friday, April 13, 2018 at 3:10 AM
> > *To: *"???(??)" <[e-mail]>
> > *Cc: *"[e-mail]" <[e-mail]>, mpls <[e-mail]>,
> > Robert Raszuk <[e-mail]>, "[e-mail]" <[e-mail]>
> > *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 <[e-mail]> <[e-mail]>
> >
> > 2018?4?13?(???) 13:27
> >
> > ???(??) <[e-mail]> <[e-mail]>
> >
> > mpls <[e-mail]> <[e-mail]>; "Bernier, Daniel"
> > <[e-mail]> <[e-mail]>; Robert Raszuk
> > <[e-mail]> <[e-mail]>; [e-mail] <[e-mail]>
> > <[e-mail]>; [e-mail] <[e-mail]> <[e-mail]>
> >
> > 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, ???(??) <[e-mail]> 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 <[e-mail]>
> >
> > 2018?4?12?(???) 23:04
> >
> > "Bernier, Daniel" <[e-mail]>; Robert Raszuk <
> > [e-mail]>
> >
> > [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
> >
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls
> >
> >
> >
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>
>
> ------------------------------
>
> End of mpls Digest, Vol 168, Issue 18
> *************************************
>