Re: [mpls] MPLS extension header

["Adrian Farrel" <[e-mail]>]

All,
 
I'm finding this fast-moving discussion a bit confusing.
 
Part of the problem is the discussion of all the possible use cases for the EH.
That makes it hard to focus in on the actual requirements rather than the
potential uses, and so the discussion is a bit fluid - when anyone observes that
a specific use case could be solved a different way, it can always be said that
this is not the main reason for the innovation. And, of course, it is easy to
float difficulties with other approaches (such as scaling, etc.) when the
requirements to circumvent those difficulties are speculative.
 
Thus a number of questions remain hard to pin down:
- does this approach need a fork-lift upgrade or can it be used with legacy
routers?
- can multiple EHLs be present in the stack?
- what is done with an EHL when it becomes top of stack?
- is a transit node expected to "find" the EHL if it is not top of stack?
 
To successfully answer these questions we need to know what function we are
attempting to deliver. Indeed, some of the questions may even be irrelevant!
 
But two other things strike me about the current version of the document:
 
1. The description of the deficiencies of the GAL/ACH may over-state the issues
a little. While you note that the primary application originally envisaged the
GAL at the bottom of the stack, this is not a firm requirement and the GAL may
actually appear anywhere in the stack. While it is true, as you note, that only
a limited number of control word types are allowed, the ACH channel type
provides sufficient scaling of a differentiator.  And you are correct that the
GAL only indicates the presence of a single ACH, but the construction of the
G-Ach message allows multiple "objects" to be present. Lastly you note that the
presence of the GAL (and presumably the ACH?) makes DPI and load-balancing by
inspection of the payload protocol header hard, you must understand that this is
for exactly the reason that the use of the EHL and EH would make the same
functions hard - the solution to the first case may not be of interest to the
IETF, and the second case is addressed by the entropy label.
 
2. The behaviour seems to model the IPv6 Destination Options extension header.
This may provide several lessons to us both in construction of a mechanism and
on the breadth of its applicability. Of note is how the destination options may
be present twice: once for the current destination addressed by the destination
address, and once for the ultimate destination. We should note that an EHL in
the stack is only encountered when the preceding label is popped - in that way
it is like the first type of destination option. While an EHL at the bottom of
the stack is like the second type of destination option.
 
Regards,
Adrian