Subject: [mpls] how does it work if ....

From: Loa Andersson <[email-masked]>
Date: Wed, 17 Mar 2021 22:18:25 +0800

Kireeti,

I'm looking at your slides from the joint meeting, in particular slide 
#3, where you say at thye bottom:

   "Corollary: such labels MUST NOT reach the top of stack (by popping
    labels above them)"

How is that backwards compatible.

If you  have an old LSR, that don't know to look at the bSPL or eSPL 
underneath the top label. I assume that the top label will be swapped 
and the packet forwarded.

What is the pen-ultimate LSR is "old" and just pop the top label, how 
can the PE sort this out?

/Loa
-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 17 Mar 2021 16:34:38 +0000

You only pop the label to see the xSPL if you are the destination.

If you do not know about the xSPL you should not have been sent the packet in the first place. That would be a routing/control plane failure.

If you receive it by mistake, and consider that it is for you (unlikely but possible) so you pop the label, you will find an unknown xSPL and presumably drop the packet.

So I that is safe.

What is going to be difficult is with one of Kireeti’s reused Els. That will work fine at a P router, but a PE is going to not process the packet properly. This cannot be a PW or Detnet since that has another label as a gatekeeper, so we nee think what happens if it is an IP packet, in which case the ECMP defeat nibble will be found. This should be unexpected, so the packet will be dropped.

If there is an old P router that does not understand the xSPL it will just swap and forward as before.

You can always program a P router not to PHP (we did that with MPLS-TP for example). It is more work for the receiving PE, but it needs to be capable of dealing with that or it should not be used in that role with this label stack.

So assuming that Kireeti and I have the same vision of how this works, it looks safe to me. However we have to look at every corner and strong exception to validate the approach.

Stewart

> On 17 Mar 2021, at 14:18, Loa Andersson <[email-masked]> wrote:
> 
> Kireeti,
> 
> I'm looking at your slides from the joint meeting, in particular slide #3, where you say at thye bottom:
> 
> If you  have an old LSR, that don't know to look at the bSPL or eSPL underneath the top label. I assume that the top label will be swapped and the packet forwarded.
> 
> What is the pen-ultimate LSR is "old" and just pop the top label, how can the PE sort this out?
> 
> /Loa
> -- 
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Loa Andersson <[email-masked]>
Date: Thu, 18 Mar 2021 02:32:10 +0800

Stewart,

Sent from my iPad

> On 18 Mar 2021, at 00:35, Stewart Bryant <[email-masked]> wrote:
> 

So HbH iOAM does not work?

/Loa

---

From: Loa Andersson <[email-masked]>
Date: Thu, 25 Mar 2021 12:56:51 +0800

Stewart,

inline please.

> You only pop the label to see the xSPL if you are the destination.

What do you mean by "destination", are you referring to the node that 
will pop the top label with the SPLs encoding information beneath? I we 
disable the PHP, thast would be the PE, right?

So that mean that we can't encode HbH behavior?

And info theat relates to forwarding is also not very useful, since the 
packet reached its destination.
> If you do not know about the xSPL you should not have been sent the packet in the first place. That would be a routing/control plane failure.

So we need some type of mechanism that tells potential ingress LER's 
which of its reachable are capable to extract inf from SPL's?

/Loa

--

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 25 Mar 2021 17:51:40 +0000

Loa

Reply in line

> On 25 Mar 2021, at 04:56, Loa Andersson <[email-masked]> wrote:
> 
> Stewart,
> 
> inline please.
> 
> What do you mean by "destination", are you referring to the node that will pop the top label with the SPLs encoding information beneath? I we disable the PHP, thast would be the PE, right?

Yes.

> So that mean that we can't encode HbH behavior?

Well, we have crossed the rubicon regarding looking further down the stack to take a forwarding decision. We did this formally with the ELI/EL pair, and have been doing it informally with the five tupple ECMP hash for a long time.

> And info theat relates to forwarding is also not very useful, since the packet reached its destination.

Indeed, so an LSR is going to have to look for this, and ideally this should be optional behaviour like the EL search is.

Presumably BTW the reason that Kireeti chose to attach his new functionality to the ELI and presumably also the EL is that his (and many other forwarders) was looking for this anyway, so it is not much more work or stack space.

> So we need some type of mechanism that tells potential ingress LER's which of its reachable are capable to extract inf from SPL's?

We need that, but we need that for any stack action other than pop single label and forward IP packet which is the only default MPLS action.

Similarly if we are forwarding along a path that needs an action we need to know that the on-path LSRs can execute that action on the packet.

So, I don’t think that this is anything beyond business as usual.

Best regards

Stewart

> Loa Andersson                        email: [email-masked] <mailto:[email-masked]>
> Senior MPLS Expert                          [email-masked] <mailto:[email-masked]>

---

From: Loa Andersson <[email-masked]>
Date: Fri, 26 Mar 2021 19:06:23 +0800

Stewart,

I understand evbery single piece yuor argument, but can't get my head 
around the it ll in the end.

You say:

So my conclusion is that if you don't pop the top label you can't see 
the info encoded in the xSPL, unless you scan the stack without popping 
the top label.  Crossing the Rubicon!

I guess that this is fine, but that seems to indicate that you have to 
scan every label stack that passes a node. And when you scan how do you 
know when to stop, it might be that the first xSPL that you encounter is 
the important one, it might be deeper down.

Wouldn't it be better to have something in the top label that tells you 
where you need to look and what you ar looking for?

I'd say that this is a FEC.

/Loa

On 26/03/2021 01:51, Stewart Bryant wrote:
> Loa
> 
> Reply in line
> 
>> On 25 Mar 2021, at 04:56, Loa Andersson <[email-masked] <mailto:[email-masked]>> 
>> wrote:
>>
>> Stewart,
>>
>> inline please.
>>
>> will pop the top label with the SPLs encoding information beneath? I 
>> we disable the PHP, thast would be the PE, right?
> 
> Yes.
> 
>>
> Well, we have crossed the rubicon regarding looking further down the 
> stack to take a forwarding decision. We did this formally with the 
> ELI/EL pair, and have been doing it informally with the five tupple ECMP 
> hash for a long time.
> 
> Indeed, so an LSR is going to have to look for this, and ideally this 
> should be optional behaviour like the EL search is.
> 
> Presumably BTW the reason that Kireeti chose to attach his new 
> functionality to the ELI and presumably also the EL is that his (and 
> many other forwarders) was looking for this anyway, so it is not much 
> more work or stack space.
> 
>>> If you do not know about the xSPL you should not have been sent the 
>>> packet in the first place. That would be a routing/control plane failure.
>>
> We need that, but we need that for any stack action other than pop 
> single label and forward IP packet which is the only default MPLS action.
> 
> Similarly if we are forwarding along a path that needs an action we need 
> to know that the on-path LSRs can execute that action on the packet.
> 
>>> If you receive it by mistake, and consider that it is for you 
>>> (unlikely but possible) so you pop the label, you will find an 
>>> unknown xSPL and presumably drop the packet.
>>> So I that is safe.
>>> What is going to be difficult is with one of Kireeti’s reused Els. 
>>> That will work fine at a P router, but a PE is going to not process 
>>> the packet properly. This cannot be a PW or Detnet since that has 
>>> another label as a gatekeeper, so we nee think what happens if it is 
>>> an IP packet, in which case the ECMP defeat nibble will be found. 
>>> This should be unexpected, so the packet will be dropped.
>>> You can always program a P router not to PHP (we did that with 
>>> MPLS-TP for example). It is more work for the receiving PE, but it 
>>> needs to be capable of dealing with that or it should not be used in 
>>> that role with this label stack.
>>> So assuming that Kireeti and I have the same vision of how this 
>>> works, it looks safe to me. However we have to look at every corner 
>>> and strong exception to validate the approach.
>>> Stewart
>>>> On 17 Mar 2021, at 14:18, Loa Andersson <[email-masked] 
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>> Kireeti,
>>>>
>>>> underneath the top label. I assume that the top label will be 
>>>> swapped and the packet forwarded.
>>>>
>>>> [email-masked] <mailto:[email-masked]>
>> Loa Andersson                        email:[email-masked] <mailto:[email-masked]>

--

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 29 Mar 2021 14:15:34 +0100

> On 26 Mar 2021, at 11:06, Loa Andersson <[email-masked]> wrote:
> 
> Stewart,
> 
> I understand evbery single piece yuor argument, but can't get my head around the it ll in the end.
> 
> You say:
> 
> So my conclusion is that if you don't pop the top label you can't see the info encoded in the xSPL, unless you scan the stack without popping the top label.  Crossing the Rubicon!
> 
> I guess that this is fine, but that seems to indicate that you have to scan every label stack that passes a node. And when you scan how do you know when to stop, it might be that the first xSPL that you encounter is the important one, it might be deeper down.
> 
> Wouldn't it be better to have something in the top label that tells you where you need to look and what you ar looking for?
> 

Loa

If you are going to use a FEC, you might as well use a FEC and only a FEC, though the downside of a FEC is the need to advertise the FEC. That is not an issue with something like RSVP, a reduced flooding scope PPR, SDN etc, where scope of knowledge/flooding is limited to the nodes that need to know, but with the general fooding label distribution methods increases the number of labels to flood, and worse allocate.

A lot of routers scan the whole stack anyway so we know you could scan to find an xSPL somewhere in the stack.

The alternative is to have a scan one below implicit action which would allow you to have a scheme where you looked at ToS if you knew no better, but look one more below if you understood the game.

So I was thinking of a top label with the meaning "Go to Foo", and an SPL below that indicating “using Bar” so the pair had the meaning “Go to Foo using the information you get from Bar”. So the label pair becomes a compound label at ToS.

We can create all sorts of syntax for this, and I am proposing to write a draft examining  some of the possibilities and issues.

So bottom line: I am thinking of using a label group rather than searching the stack in the hope of finding something.

- Stewart