Re: [mpls] Reference Augmented Forwarding - MPLS RAF

[Robert Raszuk <[e-mail]>]

Hi Tony,

Happy to see that we agree (I risk to state) on everything below.

We’ve been talking about carrying per-action capabilities for exactly this
> purpose.  If a flow aggregate needs action MNA_3, then the PCE computes a
> path along nodes that are only MNA_3 capable.  This should have zero impact
> on other flow aggregates.
>
> And remember RAF specifically targets spots not the entire network to
> execute additional network functions.
>
> I got that the first time, no need to keep repeating yourself.
>

Oh I restated this not to sound like a broken vinyl record, but to
underscore the issue I see combining the ideas.

So if I need to traverse subset of topology which support given service and
I want this service to be executed *on each node* on my flow aggregates why
not to simply use Prefix-SID and flex-algo ? Why do we need MNA for it ?
What is value add here ? Is there some delta or better advantage I am not
seeing ?

Why don't you define your actions as part of given's flex-algo
algorithm and do not use ISD nor PSD - just forward based on given
flex-algo Prefix-SID ?

Is the concern in one octet limit of the number of algorithms ? If so that
is why I wanted to better understand what physical forwarding differences
one expects to see across such topologies.

Well in the vast majority of my deployment RAF tuple should not be modified
> anywhere in the network.
>
> It must be inserted at some point.  And if MNA is used, then it must be
> inserted as well.
>

Ok I was not considering "insertion" as "modification".


Hmmm didn't you say the other day that each LSR needs to parse the entire
> stack anyway in search for SPLs ? Remember my comment during the last
> meeting .. today label stack has no offset so you do not know what it
> contains till you parse it. Heavy !
>
> This is true.  Already happening for EL.
>

I have a bit of a different opinion here .. especially for the cases where
nodes take the entire label stack as input for hashing without even
recognizing that part of that is EL.

The future of ANY feature is more about operator demand (i.e., $$$) than
> anything else.
>

100%.

Kind regards.
Robert