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, 徐小虎(义先) <xiaohu.xxh@alibaba-inc.com> 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 <stewart.bryant@gmail.com>
> 2018年4月12日(星期四) 23:04
> "Bernier, Daniel" <daniel.bernier@bell.ca>; Robert Raszuk <robert@raszuk.net>
> mpls@ietf.org <mpls@ietf.org>; sfc@ietf.org <sfc@ietf.org>
> 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
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls