[mpls] Re: Potential MNA technical issue

[Haoyu Song <[e-mail]>]

Hi Toerless,

Thanks for the detailed analysis. Considering all the existing cases, I think it's feasible and preferrable to allocate PSD immediately after the BoS and making it an integral extension of the label stack. I support this natural and straightforward solution.

Best regards,
Haoyu 

-----Original Message-----
From: Toerless Eckert <[e-mail]> 
Sent: Friday, May 2, 2025 7:52 AM
To: Stewart Bryant <[e-mail]>
Cc: [e-mail]; [e-mail]; Dongjie (Jimmy) <jie.dong=[e-mail]>; mpls <[e-mail]>
Subject: [mpls] Re: Potential MNA technical issue


I think it would be helpfull to fully understand all the quirks that existing mechanisms may have respective PSD.

The control words for PW/EVPN/DetNet seem to be "sane" in that respect,
e.g.: I am not even sure that i would need to go through "new type of PW"
as Stewart explained for PW (although that is of course an option).

All of these control words seem to have no other dependeny than being "first after MPLS BoS". So, if we for example extend the meaning of "first after MPLS BoS" to mean "in the absence of PSD, the first byte after the last LSE, in the presence of PSD after the last bute of PSD" - then all these control words should continue to operate correctly, and we wouldn't need to change any existing specs.

Of course, such an extended semantic would imply that the PSD architecture has sufficient mechanisms to safely discover the presence of PSD on PE nodes, and worst case in the forwarding plane eliminate the PSD so that the byte sequence could be made to look (internally) like it did before the existance of PSD so that the packet can be stuffed into existing control word service code in the forwarding plane.

This btw. should be possible to work even for the BIER case that i outlined in a prior mail - as long we maintain that the BoS label stays unchanged whether there is PSD or not.

Cheers
    Toerless

On Sat, Feb 22, 2025 at 10:08:36AM +0000, Stewart Bryant wrote:
> Hi Greg
> 
> I did not see an attached slide.
> 
> The way I have always viewed this is as follows
> 
> As specified a PW expects the CW or PW payload immediately after BoS and anything else in there is going to lead to incorrect behaviour. Therefore bad things happen if PSD arrives unannounced.
> 
> However if the PW component of the peer PE puts the PSD there it in effect becomes a new PW type and the two PEs will have agreed to that and the egress PE will process it appropriately. In this case the new PW designers can choose where to put the PSD - before or after the CW - so long as they avoid the DPI ECMP problem by appropriate setting of the first nibble. I don’t see why PW imposed end to end PSD would require an ISD indicator since we have PW signalling. 
> 
> If we were doing EVPN, then I would assume that we would include an indication of the presence of PSD associated with the payload in the EVPN signalling.
> 
> If the PSD was imposed by the delivery service, i.e. it is part of the delivery LSP, then this will be known by the ISD indicator mechanism. This means that the element of the egress PE responsible for LSP disposition needs to process the PSD and logically to recreate a clean packet to hand to the PW processor. In other words it has to remove the ISD indicator and the PSD before handing the packet over for PW label lookup and processing. Of course I doubt that many would implement it by strict removal and reconstruction and that the removal would be a logical removal. This optimisation is of course possible because the receiving PE knows that it just processed the PSD and it therefore knows to change its PW processing to find the CW or payload in a different place.
> 
> To make PSD and PWs work together requires engineering, but I see no showstoppers.
> 
> Stewart
> 
> > On 21 Feb 2025, at 22:05, Greg Mirsky <[e-mail]> wrote:
> > 
> > --000000000000c2d7d7062eae31b1
> > Content-Type: text/plain; charset="UTF-8"
> > Content-Transfer-Encoding: quoted-printable
> > 
> > Hi Loa,
> > I presented the attached slides on the PSD implications for DetNet 
> > and BIER. Could you point to your source for alternative 
> > interpretations of the RFCs that defined them?
> > 
> > Regards,
> > Greg
> > 
> 

> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]


--
---
[e-mail]

_______________________________________________
mpls mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]