[mpls] Re: Working Group Adoption Poll on draft-mb-mpls-ioam-dex

[Loa Andersson <[e-mail]>]

Fabian,

Misunderstand me correctly :)!

I understand what you are saying and see how you need to treat it.

What I thought you were saying is the the PSD need to be within the RLD, 
but if you place 4 octets of AD in-stack or post-stack, does not have a 
significant impact on whether it is within RLD or not, right?

/Loa

Den 26/10/2024 kl. 14:42, skrev Fabian Ihle:
> Hi Loa,
> 
> comments inline below tagged with *<FI>*
> 
> Am 26.10.2024 um 13:09 schrieb Loa Andersson:
>> Fabian,
>>
>> We are very much on the same page. Though in addition to what you say, 
>> compatibility with RFC 9326 is important for me.
>>
>> Inline please.
>>
>> Den 25/10/2024 kl. 15:50, skrev Fabian Ihle:
>>> Stewart and Loa,
>>>
>>> the "a bit trickier" part of PSD is:
>>>
>>>  1. The presence of PSD needs to be indicated efficiently. With a single
>>>     bit for indication (the "P-bit" from the jags draft), we still need
>>>     8 bytes (Format A for in-stack NAS indication and Format B for a
>>>     flag-based opcode with the P-bit set). If select-scoped PSD
>>>     indication is to be a thing, even more overhead is added.
>>>  2. In P4, the MPLS stack and the PSD must be within RLD. We cannot skip
>>>     parts of the MPLS stack that are not relevant to the current node
>>>     but have to parse the entire stack. While these irrelevant LSEs do
>>>     not need to be processed, we still have to allocate resources to
>>>     parse them. However, with an RLD of 51 LSEs, this constraint is not
>>>     a showstopper and PSD is definitely doable. But it does emphasize
>>>     the importance of the first point. Other hardware may work
>>>     differently and not have this limitation, or may be even more
>>>     constrained. In the latter case, PSD might be difficult.
>>
>> Thought experiment:
>>
>> Assume we need to transport 4 octets or mutable or variable ancillary 
>> data.
> 
> *<FI> In this case, we're only speaking of the DEX option. There is not 
> mutable or variable ancillary data in DEX. AD in DEX are only the 32-bit 
> optional sequence number and flow ID which is pushed by the 
> encapsulating node. I totally agree with you that if not using the DEX 
> option, e.g., requiring mutable or variable data with tracing, PSD is 
> much more efficient as more bits are available.*
> 
> *However, lets assume mutable data in the thought experiment.
> *
> 
>>
>> For ISD you would need
>>
>> - the MNA label
>> - a format B LSE, for the OpCode to tell what NA the AD belongs too.
>> - a Format C LSE that can carry 7 bit mutable/varaiable AD
>> - three Format D LSEs to carry 25 bits (11+11+3 bits) mutable or
>>   varaiable AD
>>
>> = 6 MNA LSEs.
>>
>> For PSD you would need
>>
>> - the MNA label
>> - a format B LSE, for the -p-bit or an OpCode to tell what NA the AD
>>   belongs to
>>
>> After the stack you would need
>>
>> - 1 LSE carrying the type
>> - 1 LSE carrying the OpCOde + 16 bit of AD
>> - 1 LSE carrying 16 bits of data
>>
>> = 5 MNA LSEs
>>
>> It seems that RLD-wise in this case PSD will be more efficient.
>>
> *<FI> The problem here is that (at least in our case) we cannot only 
> look at the number of LSEs for the NAS/PSD, but must look at the entire 
> MPLS stack. We have to parse the full MPLS stack to be able to parse the 
> PSD. Lets assume we have two forwarding labels at the top, followed by a 
> HBH NAS with the IOAM data, followed by 10 arbitrary LSEs until BoS. In 
> the ISD case for your example this means:*
> 
> *| MPLS forwarding label A |
> | MPLS forwarding label B |
> | MNA bSPL label |
> | Format B LSE (e.g. HBH scope) |*
> *| Format C LSE with 7 bit mutable data |*
> *| 3 Format D LSEs to carry 25 bits (11+11+3 bits) mutable AD | --> we 
> can stop parsing the MPLS stack here. Assuming we have two forwarding 
> labels at the top until we find our NAS we require an RLD of 8 LSEs in 
> this example.
> | Rest of the MPLS stack, lets say 10 LSEs until BoS |  --> ignored*
> 
> *Same example for PSD:*
> 
> *| MPLS forwarding label A |
> | MPLS forwarding label B |
> | MNA bSPL label |
> | Format B LSE (the PSD indicator) |
> | Rest of the MPLS stack, lets say 10 LSEs until BoS |    --> we MUST 
> parse the remaining MPLS stack to be able to parse the post-stack. Those 
> labels are not processed in the pipeline, but we have to allocate 
> resources to parse them.
>   --- BoS, PSD begins now  ---*
> *| 1 LSE carrying the type |
> **| 1 LSE carrying the OpCode + 16 bit of AD |*
> *| 1 LSE carrying 16 bits of data|                          --> Total 
> RLD of 4 LSE (top-of-stack + in-stack NAS) +  10 LSE (rest of the MPLS 
> stack) + 3 LSE (PSD) = 17 LSE*
> 
> *Other hardware may not be forced to parse the remaining MPLS stack and 
> does not have to allocate resources for them. If that is the case, i.e., 
> if there is an efficient way to go directly from the PSD indicator LSE 
> to the actual PSD, for example by skipping over with the BoS bit without 
> actually parsing those entries, the PSD case would be more efficient.*
> 
> *With that in mind, a PSD solution is compatible with RFC 9326 but has 
> some more hardware requirements (either large RLD, or efficient way to 
> parse PSD without parsing the entire stack). In contrast, the ISD 
> solution does not have those requirements (probably better for legacy 
> hardware), but has two bits less for flow ID / sequence numbers in DEX.*
> 
> *Best,*
> 
> *Fabian
> *
> 
> 
>>
>> /Loa
>>
>>>
>>> Our intention with a P4 implementation is not to deploy commercial 
>>> MNA solutions but rather to show that a protocol extension such as 
>>> the MNA framework can be implemented on constrained hardware. If it 
>>> works on constrained P4 hardware, hardware engineers will most likely 
>>> also be able to implement it. However, the reverse assumption, i.e., 
>>> "if it does not work on P4 hardware, it will also not work on other 
>>> hardware" does not apply.
>>>
>>> We have mainly focused on an ISD implementation for now, the next 
>>> step will be an extensive evaluation of the PSD version.
>>>
>>> Best,
>>>
>>> Fabian
>>>
>>>
>>> On 25.10.24 14:34, Loa Andersson wrote:
>>>> Stewart and Fabian,
>>>>
>>>> I think all implementation experiences are useful, also if the they 
>>>> are done using the commercially non-deployed P4, you can always draw 
>>>> some conclusions.
>>>>
>>>> What I would like is why PSD is trickier, and if "a bit trickier" is 
>>>> significant enough to not go with PSD. Especially since we agree 
>>>> that draft-mb-mpls-ioam-dex is not compliant with RFC 9326.
>>>>
>>>> Is "a bit trickier" the prize we pay for compliance with RFC 9326?
>>>>
>>>> /Loa
>>>>
>>>> Den 25/10/2024 kl. 13:13, skrev Stewart Bryant:
>>>>>
>>>>>
>>>>>> On 14 Oct 2024, at 10:34, Fabian Ihle <fabian.ihle@uni- 
>>>>>> tuebingen.de> wrote:
>>>>>>
>>>>>> I think that ISD is the way to go for the DEX option as an PSD 
>>>>>> implementation has proven to be a bit trickier in our P4 version.
>>>>>
>>>>> Is this an issue with the protocol or an indication of deficiencies 
>>>>> in P4?
>>>>>
>>>>> Is P4 deployed or likely to be deployed in a production 
>>>>> environment, i.e. is this a consideration for protocol 
>>>>> standardisation?
>>>>>
>>>>> Best regards
>>>>>
>>>>> Stewart
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mpls mailing list -- [e-mail]
>>>>> To unsubscribe send an email to [e-mail]
>>>>
>>> -- 
>>> Fabian Ihle
>>> Universität Tübingen
>>> Fachbereich Informatik Lehrstuhl Kommunikationsnetze
>>> Wilhelm-Schickard-Institut für Informatik
>>> Sand 13, 72076 Tübingen
>>>
>>> Raum: B303
>>> Telefonnr.: [phone]
>>> E-Mail:[e-mail]
>>> Internet: uni-tuebingen.de
>>>
>>
> -- 
> Fabian Ihle
> Universität Tübingen
> Fachbereich Informatik Lehrstuhl Kommunikationsnetze
> Wilhelm-Schickard-Institut für Informatik
> Sand 13, 72076 Tübingen
> 
> Raum: B303
> Telefonnr.: [phone]
> E-Mail:[e-mail]
> Internet: uni-tuebingen.de
> 

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