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

[Tony Li <[e-mail]>]

[WG chair hat: off]

Hi Loa,

The point is that 4 additional octets in PSD may be much farther down in the packet than it would be with ISD and thus may be outside of RLD.

Tony


> On Oct 27, 2024, at 6:36 AM, Loa Andersson - loa.pi.nu at gmail.com <[e-mail]> wrote:
> 
> 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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>
>>> >>> To unsubscribe send an email to [e-mail] <mailto:[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] <mailto:[e-mail]>
>>> > Internet: uni-tuebingen.de <http://uni-tuebingen.de/>
>>> > 
>>> 
>>> -- 
>>> Loa Andersson
>>> Senior MPLS Expert
>>> Bronze Dragon Consulting
>>> [e-mail] <mailto:[e-mail]>
>>> [e-mail] <mailto:[e-mail]>
>>> 
>>> _______________________________________________
>>> mpls mailing list -- [e-mail] <mailto:[e-mail]>
>>> To unsubscribe send an email to [e-mail] <mailto:[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]