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

[Stewart Bryant <[e-mail]>]

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]>
>     2018年4月13日(星期五) 13:27
>     徐小虎(义先) <[e-mail]>
>     mpls <[e-mail]>; "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
>
>     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
>
>     _______________________________________________
>     mpls mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/mpls
>
>