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

[Greg Mirsky <[e-mail]>]

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