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

[[e-mail]]

Hi Adrian,

Clarification questions.

> From: mpls <[e-mail]> On Behalf Of Adrian Farrel
> Sent: Wednesday, June 8, 2022 11:34 PM
> 
> Hi again, Loa,
> 
> > 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?
> 
> This is my preference of the three options that Loa floated. And I agree with Kireeti that using a bSPL is the right thing (we have some > spare, and this approach uses one label for a large set of Network Actions).
> 
> > (2) re-purposing the ELI SPL?
> 
> No way! 😊
> 
> Bruno and Zafar cast this as "extending" the ELI. In other words, in their view, this approach is backwards compatible with existing ELI > deployments. This may be technically possible,

Would it be fair to say that you don't see technical objections to raise on this approach?

> but I still don't like it because I don't think it is a clean separation of functions.

Can you clarify what you mean by "clean separation of functions"?
(because a naïve interpretation would be that you don't want to mix entropy/load balancing with Network Actions)
 
Thank you.
Regards,
--Bruno

> Conversely, some people see this as reclaiming the ELI for a new purpose.
> If the ELI is to be "reclaimed" then we need to go through a careful round of surveying implementations and a "cool-off" period during > which the label is marked as deprecated.
> If we think we don't need the ELI, we should start this now, but it is a separate action.
> 
> > (3) using some other method of indicating this such as making it an
> >     additional property of an ordinary label?
> 
> I'm open to this, but I haven't seen a credible suggestion that is backward compatible.
> 
> Tony added...
> 
> > (4) allocating a new SPL for a Network Action Sub-stack.
> 
> I think this is more embracing than 1)
> 
> Joel says...
> 
> > Stating how we do indicating information seems to belong
> > in solution drafts.
> 
> I could live with deferring this decision, but I hope we have only one solution for this particular point, so making that decision and > putting it in the Framework is also OK.
> 
> Cheers,
> Adrian
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> 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.