Re: [Pals] [mpls] Comment on draft-gandhi-mpls-ioam-sr-05

[Stewart Bryant <[e-mail]>]

There are three problems, how you encode the action and where you place the metadata, and how you accommodate anything else after BoS.

This is getting very messy and we need to solve this holistically or we will damage the future of the MPLS protocol.

The best place to indicate HxH is at ToS since this is looked at by every hop with minimum effort.

This could be via a FEC or an SPL. However I do not like the SPL approach because you probably need the EL to neutralise ECMP and that is four labels in the stack  before you even get to specify the destination. That is as many labels as some LSRs can cope with. You could I suppose have an iOAM SPL that specifies the ECMP behaviour but we are loosing our generality if we go down that route.

The best place to indicate E2E is at BoS since this is where you handle the E2E iOAM. That can be an ordinary label, and since you have to advertise E2E iOAM capability it is not much more to specify which label you expect to see BoS to indicate its presence. 

Now you have two choices to advertise both, - the ToS stuff which you do not PHP + the BoS, or one of two different BoS labels. The use of two different BoS labels is far less problematic since that is only 2 out of million available labels and you need the label in place to indicate that the packet carries E2E iOAM and not just plain IP … except that it may not carry plain IP...

Now here is what worries me.

What if the LSP is carrying a PW, or is DetNet? What if it is a MS-PW? In all these cases there is a CW immediately after BoS. Then there is the universal fragmentation idea that is floating about that also wants to follow BoS.

How do we fit in 2, possibly 3 or 4 sets of descriptor data after the BoS. This has the possibility to get very messy very quickly.

So we need to go up a level and consider how we generalise this, because iOAM needs to live with the rest of the MPLS ecosystem, and will not be the only candidate for BoS meta data. That is not to say that I have anything I want to put there that I am being quiet about, instead it is to point out that once the first genie is out of the bottle a whole bunch of their friends will soon follow behind. So we have to solve this elegantly such that we can deal with the MPLS extensions we have not yet thought of and not be tempted to just hack something in that works for the immediate case in hand.

- Stewart