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

[Loa Andersson <[e-mail]>]

Andy,

The chairs of the SPRING and MPLS wg has discussed the proposal to
adopt draft-xuclad-spring-sr-service-chaining in the MPLS wg.
Our agreement is that draft-xuclad-spring-sr-service-chaining
belongs in the SPRING wg.

/Loa
for the SPRING and MPLS wg co-chairs

On 2018-04-15 16:55, Andrew G. Malis wrote:
> 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) <zali@cisco..com 
> <mailto:[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]
>     <mailto:[e-mail]>> on behalf of "徐小虎(义先)"
>     <[e-mail] <mailto:[e-mail]>>
>     *Date: *Thursday, April 5, 2018 at 12:34 AM
>     *To: *"[e-mail] <mailto:[e-mail]>" <[e-mail]
>     <mailto:[e-mail]>>, SPRING WG List <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc: *"[e-mail] <mailto:[e-mail]>" <[e-mail]
>     <mailto:[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
>     <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
>     <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] <mailto:[e-mail]>>
>     on behalf of Stewart Bryant <[e-mail]
>     <mailto:[e-mail]>>
>     *Date: *Friday, April 13, 2018 at 3:10 AM
>     *To: *"徐小虎(义先)" <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc: *"[e-mail] <mailto:[e-mail]>" <[e-mail]
>     <mailto:[e-mail]>>, mpls <[e-mail]
>     <mailto:[e-mail]>>, Robert Raszuk <[e-mail]
>     <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>"
>     <[e-mail] <mailto:[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]><mailto:[e-mail]>____
> 
>             2018年4月13日(星期五) 13:27____
> 
>             徐小虎(义先)
>             <[e-mail]><mailto:[e-mail]>____
> 
>             mpls <[e-mail]><mailto:[e-mail]>;
>             "Bernier, Daniel"
>             <[e-mail]><mailto:[e-mail]>;
>             Robert Raszuk <[e-mail]><mailto:[e-mail]>;
>             [e-mail]<mailto:[e-mail]><[e-mail]><mailto:[e-mail]>;
>             [e-mail]<mailto:[e-mail]><[e-mail]><mailto:[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]<mailto:[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]<mailto:[e-mail]>>____
> 
>             2018年4月12日(星期四) 23:04____
> 
>             "Bernier, Daniel"
>             <[e-mail]<mailto:[e-mail]>>;
>             Robert Raszuk <[e-mail]<mailto:[e-mail]>>____
> 
>             [e-mail]<mailto:[e-mail]><[e-mail]<mailto:[e-mail]>>;
>             [e-mail]<mailto:[e-mail]><[e-mail]<mailto:[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]<mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/mpls<https://www.ietf.org/mailman/listinfo/mpls>____
> 
>             __ __
> 
>             _______________________________________________
>             mpls mailing list
>             [e-mail]<mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/mpls<https://www.ietf.org/mailman/listinfo/mpls>____
> 
>         __ __
> 
> 
> 
>     ____
> 
> 
>     _______________________________________________
>     mpls mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/mpls
>     <https://www.ietf.org/mailman/listinfo/mpls>
> 
> 
> 
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
> 

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert
Bronze Dragon Consulting             phone: [phone]