Re: [mpls] Poll 2: New SPL vs re-purposed ELI for carrying Network Action Indicators

[[e-mail]]

Tony,



Orange Restricted
From: Tony Li <[e-mail]> On Behalf Of Tony Li
Sent: Friday, June 17, 2022 3:42 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]>
Cc: Zafar Ali (zali) <[e-mail]>; Kireeti Kompella <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; DetNet Chairs <[e-mail]>
Subject: Re: [mpls] Poll 2: New SPL vs re-purposed ELI for carrying Network Action Indicators


Bruno,

Again, my problem with Bruno's draft is that the limited space found in the ELI/EL LSE's is clearly insufficient to begin to capture the use cases that we already can foresee for MNA, much less provide any room for growth.  It doesn't scale. We need more bits.

[Bruno] Thank you for providing a technical argument.
draft-decraene-mpls-slid-encoded-entropy-label-id provides 8 indicators while being backward compatible with existing egress/signaling.


And, contrary to that old TV show, 8 is not enough. :)



If more are required, solution can be extended to provide more indicators (and data) but at the cost of requiring new dataplane feature on the LSR egress (and new signaling). Just like the proposals using a new SPL.


But then you would run afoul of extending the ELI with one or more LSEs. And that's much more scary because now you're risking legacy devices misinterpreting the additional LSE's. We've discussed this, it's the same problem with Jags' draft.

Can you clarify the scenario that you have in mind when saying "you're risking legacy devices misinterpreting the additional LSE's"?

On my side, I would guess that you are referring to https://datatracker.ietf.org/doc/html/draft-li-mpls-redefining-eli#section-2.1.2
In which case I agree with you that extending ELI with one or more LSE requires 1) extension on the LSP egress and 2) signaling (to allow the LSP Egress to advertise its capability support this). I also agree that this signaling solves the problem (I quote you "Signalling the use of the MNA label stack will avoid this problem").
With the signaling above, worst case I could see is the scenario of a bug in one MPLS node sending a packet with the wrong label or to the wrong neighbor. (IMHO this is indeed a fragility of the MPLS data plane). But if we use that argument to dismiss solutions, we'll probably have to dismiss all VPN based on MPLS.

--Bruno



The net benefit is that in the short/medium term more devices/deployments can start using those 8 indicators, while waiting for the new generation to support the new proposal.


So we pay twice? Why not just have one solution?

The only thing we're really waiting for is for people to stop arguing.

Tony



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.