Re: [mpls] draft-andersson-mpls-mna-fwk

[[e-mail]]

Hi Tony,



Orange Restricted
From: Tony Li <[e-mail]> On Behalf Of Tony Li
Sent: Friday, June 10, 2022 10:00 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]>
Cc: mpls <[e-mail]>
Subject: Re: [mpls] draft-andersson-mpls-mna-fwk


Hi Bruno,

Or, are you suggesting some remapping mechanism, whereby all actions are remapped to locally defined bits.  Thus, in my domain entropy might be bit 0.  In your domain, it might be bit 6?
[Bruno] I was suggesting just this.


Ok.  Proposed text:

                                A solution may include a bit remapping mechanism so that a given domain may optimize for its commonly used actions.

[Bruno2] Much better than my text. Thank you. Works for me.

We are proposing adding signaling that indicates MNA capable systems.  Any system pushing a stack including MNA should compute a path that only includes MNA routers.  In cases where the path can change without warning, management would need to ensure that all possible alternative paths are MNA enabled.
[Bruno] OK. I’ll need some time to think about this.
Preliminary personal feedbacks:
- I think that this should be explicitly indicated in the draft.


Please see section 2.3. If the wording seems unclear, please feel free to propose clarifications.

[Bruno2] §2.3 explains the need for signaling and is mostly fine, although the last paragraph refers to ingress behavior. §2.2 describes partial processing on nodes and probably could talk about this.
If we want to follow that path (of been not backward compatible) I’d propose the following clarification:
§2 “Legacy transit SR compliant with RFC3031 are allowed to scan the whole label stack. This framework allows for MNA to encode, in the LSE.Label field, a value in the reserved label space (0-15) [RFC3032]. This may not be backward compatible with existing and future used of reserved label. In order to avoid ‘train wreck’ the ingress LER pushing the MNA in the LSE MUST ensure that all downstream nodes supports MNA.”

However, my preference would be for a solution being backward compatible with existing transit LSR (not needing to act on the MSA) and avoiding ‘train wreck’.
I would prefer that this framework do not take position for one option. But describe both with there tradeoffs.

And if someone clever can spell out the consequences of traversing an MNA incapable router, that would be helpful, at least to me.


The words ’train wreck’ come to mind. :)
[Bruno2] Works for me 😉



- Yes I think that the path can change without warning, in particular for long lives usages of MNA. E.g. if MNA is designed to encode entropy and replace ELI.


I agree.



- As you are well aware, FRR is a local feature with different flavours (LFA, RLFA, TI-LFA, link protection, node protection, (local) SRLG protection…) each translating into different protection paths. That seems computationally expensive to me for the ingress to compute all possible alternatives paths for all FRR flavours for all nodes/PLR along the path.


Presumably an LSP is only expecting some small number of types of FRR. No point in worrying about non-applicable situations.
[Bruno2] Yes, the number of types for FRR which have been implemented and deployed. The point is that the ingress would need to know and consider that. Even for the typical FRR types (LFA, RLFA, TI-LFA, and assuming that the type of protection (link vs node) is consistent along the path which IMO is debatable as I would likely configure node protection only for node which are prone to failures) that would typically require the ingress to compute at multiple SPFs per node in the flooding domain. I’m not convinced that ingress would do that. So if the consequence of not doing that is possible train wreck, I think that this merit further WG discussions.



Plus in many cases, IMHO that set of all paths would, in the end, require all possible transit nodes to be MNA capable. In my environments with multiple vendors, multiple platforms, multiple generations… I would a priori find it hard to have all routers MNA capable in a foreseeable future.


And for all actions.  Yes, this is why signaling needs to be specific.
[Bruno2] Signaling is fine. Requiring MNA support on nodes which are required to act on a given action is fine. What I find debatable is requiring MNA support on all possible downstream nodes, under any (rerouting) conditions. And failure to achieve this translating in train wreck.
My personal preference would be to have a solution allowing legacy nodes on the path without having train wreck.



- To me, RFC6790 (EL) had a much friendlier deployment path by mandating that LSE label values (just the EL in RFC6790 case) did not include value in the reserved label space. (§3) Same thing for draft-jags-mpls-ext-hdr where we avoided the appearance of reserved SPLs in a LSE.Label field.


Understood, but with more generality, placing a similar constraint on all of the in-stack data seems onerous, whereas we are already going to have signaling requirements, regardless.
[Bruno2] I agree that there are tradeoffs. I feel that they should to be discussed in the WG and at minimum that the framework should allow for solution exploring both paths.
I can see that the tradeoffs may be quite different depending on the deployments conditions (e.g. mono vendor vs multi-vendor, size of the network, greenfield vs brownfield). On my side, I’d expect issues with some of the network that I’m aware of.
Signaling is not the issue. IMHO the issue is mandating that the ingress guarantee that the MNA only cross MNA capable LSR whatever possible features/rerouting conditions on downstream nodes, and the consequences been train wreck.

--Bruno

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.