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

[Tony Li <[e-mail]>]

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.  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.

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?


> 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.

Tony