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

[Stewart Bryant <[e-mail]>]

Hi Robert,

On 12/04/2018 17:31, Robert Raszuk wrote:
> Hi Stewart,
>
> 1.
>
> > In its simplest form it uses a compact MPLS stack to describe an 
> arbitarily complex path
>
> What exactly is "compact" in MPLS label stack as defined in 
> draft-ietf-mpls-sfc ?

I was talking about the lable swapping method in Section 5.

The section 6 text below makes sense when you need to concatinate a 
number of tuples. Obviously there comes a point where optimum stack size 
swaps from one design to the other. That is why I don't want to make a 
choice without understanding the properties and operational considerations.

>
>
>       -------------------
>      ~   Tunnel Labels   ~
>      +-------------------+
>      ~     Optional      ~
>      ~   Entropy Label   ~
>      +-------------------+ - - -
>      | SFC Context Label |
>      +-------------------+  Basic unit of MPLS label stack for SFC
>      |     SF Label      |
>      +-------------------+ - - -
>      | SFC Context Label |
>      +-------------------+  Basic unit of MPLS label stack for SFC
>      |     SF Label      |
>      +-------------------+ - - -
>      ~                   ~
>      +-------------------+ - - -
>      | SFC Context Label |
>      +-------------------+  Basic unit of MPLS label stack for SFC
>      |     SF Label      |
>      +-------------------+ - - -
>      |                   |
>      ~    Payload        ~
>      |                   |
>       -------------------
>
>             Figure 3: The MPLS SFC Label Stack for Label Stacking
>
> 2.
>
> > draft-xu-clad-spring-sr-service-chaining unrolls the path and 
> explicitly calls out each hop
> > and each function into the label stack.
>
> That is precisely what draft-ietf-mpls-sfc also does as far as SF's 
> are concerned.

No, it has two modes, each with different properties, and these have 
different properties from draft-xu-clad.

>
> Other network elements which do not participate in SFs are not aware 
> of service function states and all they are doing is transporting mpls 
> packets to and between SFs. Both drafts are identical here.
>
> What differences in network state do you see in transit nodes ? With 
> that please keep in mind that LDP's network state with locally 
> significant labels is far greater then SR network state with 
> global/domain wide labels.

Are well, there is the whole question of whether nodal labels in the IGP 
is SR or MPLS. My understanding of the archaeology of MPLS is that 
putting such labels in the IGP was the original design choice, but this 
was abandoned in favour of more expeditious deployment ... but we digress.

You base question is however more complex than it seems on the surface. 
NP memory state is enormously more expensive ($$$) than route processor 
state. SR pushes that expensive state to the most cost sensitive 
components in the network (the ingress routers). The payback is a 
reduction in path state in the core. On the otherhand binding SIDs add 
back that state. So this question can only be adresssed in the wider 
contest of the network topology, the application set, the implementation 
constraints and the set of SR features needed.

>
> Last the core of the comments where focused on using NSH and not to 
> make any judgement which way of producing alternatives to it is 
> better/worse.

If you have end to end NSH, then use it. Both of these drafts focus on 
what to do if you do not have end to end  NSH technology available.

- Stewart

>
> Best,
> R.
>
>
> On Thu, Apr 12, 2018 at 5:04 PM, Stewart Bryant 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>
>     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
>
>