[mpls] Re: #6 The select problem

[Adrian Farrel <[e-mail]>]

I don’t see how anything except HBH works or is intended to work along the path of an LSP. 

I2E targets only the end of the label stack.

Select targets the node that does a pop.

 

A

 

From: Loa Andersson <[e-mail]> 
Sent: 18 April 2025 16:07
To: [e-mail]
Cc: Loa Andersson <[e-mail]>; Joel Halpern <[e-mail]>; Dongjie (Jimmy) <jie.dong=[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [mpls] Re: #6 The select problem

 

Adrian,

 

I see two differences

 

- in select scope the LSP may continue when the last sect scope NAS has been popped. That can’t happen in  I2E scope

- the select scope NAS may be repeated, that can’t happen in I2E scope. 

 

I’m struggling to make select work in a swap environment, so far I have not succeeded. 

 

/Loa

 

On Fri, 18 Apr 2025 at 22:06, Adrian Farrel <[e-mail] <mailto:[e-mail]> > wrote:

I've been pondering this for a while because in "traditional" MPLS, the Select substack only reaches top of stack when a label is popped. That would only happen at the end of an LSP.
Historically, we have called the end of an LSP an "egress" although I think the MNA documents have more specifically described the "egress" as the edge of the MPLS network.

Now, Tony's reminder (thanks, Tony) that SR-MPLS consists of popping within the network (at the end of a segment) makes the Select concept more meaningful. (Who knows or cares whether we consider the end of a segment to be the end of a hierarchical LSP?).

Let us consider, however, the behaviour of the I2E substack. This substack is found only at the egress edge of the MPLS label stack when the final forwarding label is popped (PHP considered as a different issue). In this case, the I2E substack is raised to top of stack and processed. That seems to me to be identical to the Select behaviour. 

While it is true that Select and I2E are targeting different points in the network, they are both only processed when they come to top of stack. So, do we actually need a discriminator (effectively a bit flag) to say whether it was intentional that the substack reached top of stack?

I.e., do we need both Select and I2E values in the IHS?

Give me an example of where the distinction is truly needed and I will fold. Otherwise, We can save a bit from the IHS (releasing it to be Reserved).

Cheers,
Adrian

-----Original Message-----
From: Loa Andersson <[e-mail] <mailto:[e-mail]> > 
Sent: 18 April 2025 09:35
To: Joel Halpern <[e-mail] <mailto:[e-mail]> >; Dongjie (Jimmy) <jie.dong=[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Cc: [e-mail] <mailto:[e-mail]> 
Subject: [mpls] Re: #6 The select problem

Joel,

Plz, look sat the discussion I have with Tony on the select problem, 
there are things there that asfter closer consideration might have an 
impact on this response.

Tony says that the select scope does not work well with the label 
swapping paradfigm and is better suited with the label popping paradigm 
of e,g, SR-MPLS.

Note: I need to think more about this before I concede this point. But I 
understand Tony's point.

For the time being I think that draft-ietf-mpls-mna-hdr gices me some 
support in saying that that a MNA Label may reach a node on top of the 
label stack (end of section 7.):

    Transit, non-penultimate nodes that pop a forwarding label and expose
    a copy of a NAS MUST remove it.

    A node performing Penultimate Hop Popping (PHP) that pops the
    forwarding label with only the NAS(es) remaining on the stack MUST
    NOT remove the NAS(es).  Instead, it forwards the packet with the
    NAS(es) at the top of stack to the next node.

    The node that receives the NAS at the top of the label stack MUST
    remove it.

I don't think that the above and your statement:

   The diagram seems wrong since the MNA label should never be the top
   label of the stack.

Can both be right.

How does this concern the draft-ietf-mpls-mna-hdr and 
draft-jags-mpls-ps-mna-hdr both need to indicate that all the 
information needed, for any of the scopes, is not available through the 
data plane only, but either a control plane or management plane is needed.

/Loa

Den 17/04/2025 kl. 21:54, skrev Joel Halpern:
> Well....
> 
> I am pretty sure that we agreee that the information is needed.
> 
> The diagram seems wrong since the MNA label shoul dnever be the top 
> label of the stack.
> 
> But more importantly, I do not understand how this question relates to 
> the ISD draft.   The draft is not about the control or management plane 
> operations.  And the need for the information is orthogonal to the 
> encoding of in-stack or post-stack operations.
> 
> I2E scope (for both in-stack and post-stack) does require knowing the 
> capabilities and identity of the E node.  That was true even if there 
> were no operations.
> 
> So what is the question / concern?
> 
> Yours,
> 
> Joel
> 
> On 4/17/2025 6:52 AM, Loa Andersson wrote:
>> Joel, et.al <http://et.al> .,
>>
>> At lest there is something that we are close to agree upon here.
>>
>> "...the entity constructing the stack needs to know which nodes need 
>> the instructions, and needs to include labels for directing the packet 
>> to that node..."
>>
>> Part of the question is probably where the info comes from.
>>
>> That seem to be equally true for an I2E scope as for a select.
>>
>> I2E scope model:
>>
>> +----+       +----+       +----+       +----+
>> | I  |-------| T1 |-------| T2 |-------| E  |
>> +----+       +----+       +----+       +----+
>>
>> I = Ingress
>> T = Transit
>> E = Egress
>>
>> Label stack per hop
>>
>>    +-----+        +-----+        +-----+
>>    |  t1 |  ----> |  t2 |  ----> |  m  |
>>    +-----+        +-----+        +-----+
>>    |  m  |        |  m  |        |  b  |
>>    +-----+        +-----+        +-----+
>>    |  b  |        |  b  |
>>    +-----+        +-----+
>>
>> t   = transport label
>> m   = mna label
>> b   = LSE type B
>> m+b = the NAS
>>
>> Summary:
>> - I build the stack and forward to first T1
>> - T1 swaps t1 to t2, and forward to T2
>> - T2 pops t2 and forward to E
>> - E performs the NA and pops the NAS
>>
>>
>> Select scope model:
>>
>>
>> +----+       +----+       +----+       +----+        +----+ +----+
>> | I  |-------| T1 |-------| T2 |-------| S  |--------| T3 |------| E  |
>> +----+       +----+       +----+       +----+        +----+ +----+
>>
>> I = Ingress
>> T = Transit
>> E = Egress
>> S = Select
>>
>> Label stack per hop
>>
>>    +-----+        +-----+       +-----+       +-----+ +-----+
>>    |  t1 |  ----> |  t2 | ----> |  m  | ----> |  u2 | ----> | pl  |
>>    +-----+        +-----+       +-----+       +-----+ +-----+
>>    |  m  |        |  m  |       |  b  |       | pl  |
>>    +-----+        +-----+       +-----+       +-----+
>>    |  b  |        |  b  |       |  u1 |
>>    +-----+        +-----+       +-----+
>>    |  u1 |        |  u1 |       | pl  |
>>    +-----+        +-----+       +-----+
>>    |  pl |        |  pl |
>>
>> t   = transport label
>> m   = mna label
>> b   = LSE type B
>> m+b = the NAS
>> u   = transport label
>> pl  = pay load
>>
>> Summary:
>> - I build the stack and forward to T1
>> - T1 swaps t1 to t2, and forward to T2
>> - T2 pops t2 and forward to S
>> - S performs the NA and pops the NAS, finds u1 and swaps to u2,
>>   forward to T3
>> - T3 pops u2, and forward to E
>>
>> Do we reasonably agree this far?
>>
>> I have a couple of further questions but let us see if we agree this far.
>>
>> /Loa
>>
>>
>> Den 17/04/2025 kl. 01:33, skrev Joel Halpern:
>>
>>> 6) You seem to see a problem with handling select scope.
>>>
>>> Response 6) As far as I can tell, the ISD select scope handling 
>>> precisely matches the need.   Yes, the entity constructing the stack 
>>> needs to know which nodes need the instructions, and needs to include 
>>> labels for directing the packet to that node and the associated 
>>> instructions.   No matter how you encode the packet, you need that 
>>> information if the packet is going to reflect the control.  The 
>>> alternative would seem to be to declare Select to be out of scope, 
>>> which would seem to be a violation of the agreed requirements.
>>>
>>

-- 
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
[e-mail] <mailto:[e-mail]> 
[e-mail] <mailto:[e-mail]> 

_______________________________________________
mpls mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 

_______________________________________________
mpls mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]>