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

[Loa Andersson <[e-mail]>]

Greg, 

I’m just saying that adding e.g 4 octets of ancillary data to a MPLS packet, will impact the RLD the same regardless if you do it as ISD or PSD. 

/Loa

Sent from my iPhone

On 26 Oct 2024, at 18:13, Greg Mirsky <[e-mail]> wrote:



Hi Loa,

it seems that you misinterpreted RLD for LSE overhead introduced by ISD or PSD. I think that in regard to RLD, PSD will always demonstrate worse than ISD for HbH and Select modes because there highly likely be a number of LSEs and probably other Post-stack headers between NAS and PSD block.

Regards,

Greg

On Sat, Oct 26, 2024 at 4:09 AM Loa Andersson <[e-mail]> wrote:

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.

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.


/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: http://uni-tuebingen.de" rel="noreferrer nofollow" target="_blank">uni-tuebingen.de
>

--
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]