[mpls] Re: Potential MNA technical issue - late follow up

[John Drake <[e-mail]>]

 Greg is right.  If we don't adopt an Opcode/Offset approach now, we will end up adopting it later.  The P Flag is just about useless.
On Sunday, April 27, 2025 at 06:09:14 PM PDT, Greg Mirsky <[e-mail]> wrote: 
 
 
 
Hi Loa,

I have some notes about signaling PSD, but first, a question:

What is the interpretation of P-flag == 0?

I see several benefits of using a dedicated Opcode option to signal the presence and location of a PSD header:
   
   - the single mechanism makes for a more robust implementation;
   - the order of Opcodes provides a clear principle to signal the order of processing for MNA AD;
   - easy integration with technologies that use their own PSH;
   - allows for using multiple PSD headers.

Yes, the Opcode option has some overhead but also benefits (see above). Although P-flag might seem like a simpler option for many use cases, it does not support all scenarios and still requires some additional mechanism. If that is the case, and following the "Make your worst case your normal case" philosophy, I support using the Opcode option as the only mechanism to signal the presence and location of the PSD header.






Regards,

Greg

On Sun, Apr 27, 2025 at 2:07 AM Loa Andersson <[e-mail]> wrote:

Tony,

Den 27/04/2025 kl. 13:53, skrev Tony Li:
> 
> Hi Loa,
> 
> 
>>> We still have not resolved how PSD will be indicated.  We have four proposals on the table.  When we come to consensus, then it will be obvious where to put it.
>>> a) P-bit in the ISD header. This lacks any offset, which makes it difficult to find the PSD on mid-path nodes where other post-stack information might be above it.
>>
>> I think that the P-flag can only be used if PSD immediately follows the LSE that has the BoS set.
> 
> 
> Having the P bit indicate an offset of zero is one possibility. That seems like the cost of a bit always to optimize for a case that might happen sometimes. To my way of thinking, that’s kind of expensive.
> 
> 
>> You say that using the P-flag is a problem for transit nodes "where other post-stack information might be above it". Why does not the egress node have the same problem?
> 
> 
> The egress node might have other information about what’s in the payload and thus what’s after the stack. If it doesn’t know what’s coming, then yes, it too would need the P-flag or an offset.
> 
> 
>>> b) An offset as an opcode.
>>> c) Offsets per PSD action.
>>> d) Some combination of the above.
>>> I favor option b as it’s simple and sufficient.
>>
>> You say you favor option b, I might agree with you. I option b that we have an OpCode (indicating "PSD present") followed by a 13 or 16 bit field (depending on type of LSE) containing the offset?
>>
>> Like this:
>>
>>
>>     0                   1                   2                   3
>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    | Opcode=PSD  |      Offset             |R|IHS|S|U|  NASL | NAL |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>                  Figure 2: LSE Format B: The initial opcode
> 
> 
> Yes, that would be one way.
> 
> 
>>    LSE Format C is used to encode the subsequent opcodes in the NAS.
>>
>>     0                   1                   2                   3
>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    | Opcode=PSD  |            Offset             |S|U|  Data | NAL |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>                  Figure 3: LSE Format C: Subsequent opcodes
>>
>> Then setting the P-flag would be semantically equal to having an offset of "0", and I see no harm in including it.
> 
> 
> Again it burns a bit.  If it’s something that’s used frequently, then it might be worthwhile.  If it is used infrequently, then it would seem to be expensive. It all depends on what your expectations are.

So looking at LSPs with PSD immediately after the LSE with the BoS-bit 
set what this comes down to is that:

- if there are twenty packets carrying the p-flag, and only one of these
flags are set this is equivalent with one packet with OpCode + 13 bits

- if there are 1 in 21 (or less) p-flags set, the OpCode + offset is 
more efficient

- if there are 1 in 19 (or more) p-flags set, then p-flags are more 
efficient

Then of course we have to do something with the P/R-bit, if we just turn 
it into more data-bit as long as the data field is not filled. If 90% of 
the data is 13 bits or less, you have to carry the that extra bit anyway,

SO my problem that I don't know the "expectations", anyone that have Ideas?

/Loa

> 
> 
>> Did I understand you correctly?
> 
> 
> I think so.
> 
> T
> 

-- 
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
[e-mail]
[e-mail]

_______________________________________________
mpls mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]

_______________________________________________
mpls mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]