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

["Zafar Ali (zali)" <[e-mail]>]

Hi Tony,

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

The encoding in Bruno’s draft is sufficient for many, if not most use-cases
I would also like to point you to IETF113 PALS joint WG session minutes where many find encoding sufficient: https://datatracker.ietf.org/doc/minutes-113-pals/

Re: It (Bruno’s draft) doesn’t scale

To me the complex encoding, need for pushing additional labels (the reality is that depreciating ELI is a wishful thinking), etc. is more unscalable and requires more HW resources. Simplicity is the basis for MPLS data plane design and what makes it scalable.

Thanks

Regards … Zafar


From: Tony Li <[e-mail]> on behalf of Tony Li <[e-mail]>
Date: Friday, June 17, 2022 at 9:42 AM
To: "[e-mail]" <[e-mail]>
Cc: "Zafar Ali (zali)" <[e-mail]>, Kireeti Kompella <[e-mail]>, "[e-mail]" <[e-mail]>, "[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.



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