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

[[e-mail]]

Hi Tony,


Thanks for your answer.
Please see inline [Bruno]



Orange Restricted
From: Tony Li <[e-mail]> On Behalf Of Tony Li
Sent: Thursday, June 9, 2022 4:46 PM



Hi Bruno,

Please see inline.


[Bruno] I'm all for having a common standard. I would not be there otherwise.
I think it would be possible to have a standard Network Action behavior, a standard code for that behavior, but to associate that behavior/code to a specific bit via a "limited domain" specific catalog. A bit like MPLS which associate a behavior/FEC to a given label value. Such approach would reduce the size of the catalog. And this seems an advantage since we both agree that the size of the catalog negatively impacts the efficiency of using bit catalogs.


Sorry, I'm not following you.
[Bruno] I apologize for that. Thank you for efforts.

 I think you're suggesting that MNA should support both standardized and locally defined actions. And that this be encoded by having a bit that indicates whether the catalog is standardized or local.  That's not impossible, but does cost a bit.
[Bruno] I was not suggesting this.

It seems to me that if a solution chooses bit catalogs, then it could also just set aside a few bits for locally defined actions.  This would seem to serve the same purpose.


OLD :
Catalogs are efficient if the number of present network actions is
   relatively high and if the size of the necessary catalog is small.

NEW
Catalogs are efficient if the number of present network actions is
   relatively high and if the size of the necessary catalog is small.
As MPLS works within a limited domain, one way of having a smaller catalog would be to have a private catalog containing only the network actions used within such limited domain. Such benefit would be at the cost of increased signaling or management (to associate bits and network actions) and possibly increased PFE complexity.


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.



I'm not sure that [RFC3031) has requirements for LSE which are not a the top of the stack. However, it's probably safer to forbid NAS to use values 0-15 in the "label" part of the LSE, in order to avoid an LSR scanning the whole stack wrongly recognize a wrong bSPL (e.g. EL or the MAN label). If so I think it should be indicated in this document.
This is why MNA should never be sent through systems that don't recognize MNA.  They could easily interpret AD as ELI, for example.

I understand the restriction that you're suggesting, but I don't think we want to go that far.  It grossly limits what we can do with AD.
[Bruno] I agree those are two options with their own trade-offs. This may be a technical detail of a given proposal, but I think we should discuss both options in the WG. At least on my side I was assuming "my" option, while you seem to assume "your" option
I may be missing something obvious, but I'm not sure how one ensure that "MNA should never be sent through systems that don't recognize MNA". In particular the ingress has not absolute control of the path taken by the packet (e.g. Fast ReRoute, IGP convergence on the path, use of Binding SID in SR-MPLS where the binding SID hides the forwarding SIDs hence the path...


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. And if someone clever can spell out the consequences of traversing an MNA incapable router, that would be helpful, at least to 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.
- 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. 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.
- 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.
- In such case, I would probably call for using post stack data as much as possible, rather than in stack data.

Hopefully, I'm missing something (e.g. too tired or worst). So I need some more time to think about this.

Many thanks for the discussion.
Regards,
--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.