[mpls] Re: Potential MNA technical issue

[John Drake <[e-mail]>]

 
Stewart,
Given that we have a number of deployed MPLS "applications" (PW, iOAM, BIER, GAL/GaCH, Detnet) which already put data after the Bottom-of-Stack, it seems that the question is how MNA PSD will interact with these applications. You seem to be saying that you want all such applications in nodes supporting MNA PSD to be modified to understand MNA PSD.  That seems to be a big and completely unnecessary ask.
Rather, I think if we decide to use MNA PSD, we have to introduce it in such a way that existing, or future applications, are blissfully unaware of it. I.e., MNA PSD should have no interactions with existing or future MPLS applications.  

    On Monday, February 24, 2025 at 03:15:26 AM PST, Stewart Bryant <[e-mail]> wrote:  
 
 John
If the PSD relates to the application it goes without saying that the application needs engineering work.
If the PSD relates to the delivery LSP, then it is the responsibility of the delivery LSP processing to do this transparently WRT the application. Any optimisation however is the remit of the implementor.
If the PSD relates to both delivery and payload case 1 above applies.Stewart

On 22 Feb 2025, at 20:02, [e-mail] wrote:

Stewart,
I think the point is that if you require PSD  immediately after BoS, rather than after any application data that may be present after BoS, it will require every such application to be re-written.  This is a big problem.
Sent from my iPhone

On Feb 22, 2025, at 2:39 PM, Stewart Bryant <[e-mail]> wrote:




John
I was asked about PW so that is what I replied about.
There is no iOAM embedded in PW as far as I know.
I EVPV can be handled by configuration, management plane or advertising according to the preference of the EVPN specialists.
Stewart

On 22 Feb 2025, at 18:46, [e-mail] wrote:




Stewart,
Your universe seems limited to PWs, which is fine but incomplete for the problems we need to solve - there are already other applications using post stack data and more all the time, such as the IOAM draft Tony mentioned to Loa.
For your information,  EVPN does not use signaling and does not necessarily use a CW.
Sent from my iPhone

On Feb 22, 2025, at 5:09 AM, Stewart Bryant <[e-mail]> 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]