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

[Fabian Ihle <[e-mail]>]

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 
>>>>> <[e-mail]> 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