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

Hi Kireeti,

Thank you for actively contributing to the discussion. Although after the poll.
Please see inline [Bruno]

> From: Kireeti Kompella <kireeti.ietf@gmail.com>
> 
> Hi Bruno,
> 
> I disagree: talking with our hardware folks, there are fixed pipeline PFEs where the parsing of the ELI and the following EL is hardcoded.  These PFEs will not be able to insert or parse the SLID, nor any network actions.

[Bruno] I'm not seeing disagreement, as we are talking about two different aspects:
- I'm talking about the protocol extension being discussed at the IETF. And again, I haven't seen a technical argument blocking that protocol extension
- You are talking about a specific implementation. A decade ago at the IETF that argument would have been dismissed by replying that "this is an implementation issue"

>   So, this draft repurposing ELI is a non-starter for many many deployed devices.

[Bruno] This is often the case; vendors used to call these "legacy equipment" and call for those being replaced.
And this is something even true for control plane features. I have a very recent case with FlexAlgo.

With regards to implementations, it's true that some may be more or less flexible. The less flexible ones may require a new generation in order to support a new data plane feature. This seems likely to be true regardless of the value of the SPL.
BTW, are you saying that draft-kompella-mpls-mspl4fa will run on all deployed devices?

--Bruno

> In general, repurposing any SPL already defined today is a bad idea.  In the future, any new SPL that is defined should have clear guidelines on how one can update its function(s).  Going outside of those guidelines would be “repurposing” and should not be allowed.
> 
> Kireeti.
> 
> > On Jun 8, 2022, at 11:15, bruno.decraene@orange.com wrote:
> >
> > I believe that extending the ELI bSPL is technically possible to indicate the presence of a Network Action and any Ancillary Data as per the MPLS Network Actions (MNA) framework. And so far, IINM, I have not seen a technical argument against.
> >
> > I believe that extending the ELI bSPL is a better approach compared to allocating a new bSPL (and likely redefining a new way to encode entropy while we already have a solution and deployments for this)
> >
> > Thank you,
> > Regards,
> > --Bruno
> >
> >
> > Orange Restricted
> >
> > -----Original Message-----
> > From: mpls <mpls-bounces@ietf.org> On Behalf Of Loa Andersson
> > Sent: Monday, May 30, 2022 11:22 PM
> > To: mpls@ietf.org
> > Cc: mpls-chairs@ietf.org; pals-chairs@ietf.org; DetNet Chairs <detnet-chairs@ietf.org>
> > Subject: [mpls] Poll 2: New SPL vs re-purposed ELI for carrying Network Action Indicators
> >
> > MPLS Working Group, MPLS Open DT,
> >
> > The MPLS Network Actions (MNA) framework requires a method of indicating
> > the presence of a Network Action and any Ancillary Data.
> >
> > Is the consensus of the working group that we do this by:
> >
> >   (1) allocating a new SPL for Network Action Indicators?
> >
> >   (2) re-purposing the ELI SPL?
> >
> >   (3) using some other method of indicating this such as making it an
> >       additional property of an ordinary label?
> >
> > Please respond to the MPLS WG mail list.
> >
> > Loa Andersson
> > for the Open DT wg chairs
> >
> > --
> > Loa Andersson                        email: loa@pi.nu
> > Senior MPLS Expert                          loa.pi.nu@gmail.com
> > Bronze Dragon Consulting             phone: +46 739 81 21 64
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls
> >
> > _________________________________________________________________________________________________________________________
> >
> > 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.
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls

Orange Restricted

_________________________________________________________________________________________________________________________

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.