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

[Stewart Bryant <[e-mail]>]

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