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

[Tony Li <[e-mail]>]

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.


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


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


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


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


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


Tony