Re: [mpls] MPLS extension header

[Haoyu song <[e-mail]>]

Hi Adrian,

Please find my response inline.

Best,
Haoyu

From: Adrian Farrel [mailto:[e-mail]]
Sent: Friday, August 10, 2018 8:04 AM
To: [e-mail]
Cc: Haoyu song <[e-mail]>
Subject: RE: [mpls] MPLS extension header

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?
[HS] For legacy routers, if they don't need to access the upper layer and they don't need to scan and understand every label, then they can still forward packets with EHs.
Otherwise, a fork-lift upgrade is needed.

- can multiple EHLs be present in the stack?
[HS] I don't see why this is needed but there's no fundamental reason why it can't be done.

- what is done with an EHL when it becomes top of stack?
[HS] Pop it if a label below it needs to be accessed. Then push it back if EHs are still present.

- is a transit node expected to "find" the EHL if it is not top of stack?
[HS] If it's capable and configured to process EHs, the node should try to find EHL in each packet.

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.
[HS] I have discussed this point in another email. And in the draft we explained why we don't want to further overload the GAL sematics. But anyway if there is a strong  argument and consensus to reuse GAL as the indicator, we won't object it. The main contribution of this draft is the way to support multiple chained EHs. We are open to select the indicator approach for EHs.

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.
[HS] This is an interesting observation. Currently we just assume that every configured node will check for EHL in the entire label stack and then search for the EHs it is configured to process if an EHL is found. What you said seems to suggest to associate an EHL to a particular destination, hence we can have more control and realize something like hop-by-hop EH and end-to-end EH. I think we can explore this possibility further.

Regards,
Adrian