Re: [mpls] Reference Augmented Forwarding - MPLS RAF

[Robert Raszuk <[e-mail]>]

Hi Tony,

I am no expert on slicing and I cannot tell you all of the ways that GISS
> might be used.  I can speculate some for you:
>
> - One might have a mapping from GISS to FlexAlgo topology.
>

Ok. And do you expect to have how many parallel flex-algo topologies
running in a network. And even that is not real question,. Real question is
how one such topology differ from the other to get into 2^10 slices or even
let's go lower and say 2^8 ?


> - One might want to ensure that package for a given slice only leaves the
> underlay on an exit link for the same slice.
>   This would be an authentication check only on the exit router.
>

Ok. Don't we have EPE for this ? Or are you saying that we do not trust EPE
and want to just double check ?


> - One might just use GISS as ’security theatre’ and carry overhead in
> every packet without any check. All cost, no benefit.
>

:)

One of these seem much more likely than the others.  If you’re suggesting
> that there will not be 2^10 different topologies, I would concur. That’s
> not sustainable.
>

Ok.


> Again, this is more of a conversation for TEAS.  Yes, some view a slice as
> simply an overlay. Some argue that it’s just a VPN.
>

I realize this is not the right WG for this, but I am drilling it here as I
see "slice" buzzword is being used as one of major justification for this
work.

Well when Tarek brought up the topic of user defined actions (considering
> action as action aggregate) for MNA it came apparent that the scheme only
> would differ from RAF in few elements:
>
> * distribution model of such actions:  domain wide vs per dst node;
>
> * collisions handling with other actions in the same ISD/PSD
>
> * ordering of actions (ordered list in ISD/PSD) as opposed to completely
> define it by control/mgmt plane
>
> * location of RFV on the stack (ISD can be anywhere and there can be
> multiple of them, RAF can be only after top most label or instead of one)
>
> * You said: "RFV would then become ancillary data for the function" -
> that means that we either cut the RFV size or use two LSE to signal it
>
> No, I’m suggesting that you could expand RFV to 31 bits.
>

I am not sure I see a need. For my view of practical use cases even 20 bits
is more then enough.

But you said RFV would be a parameter to an MNA action - correct ?

Where would this action be placed ? ISD after top label only ? Any ISD ?
Any ISD or PSD ?

Then where would the parameter sit ? Immediately behind the action ?
Somewhere else ?

Would action be in ISD and parameters in PSD ?

That's why I am skeptical and till I undersand those details it is very
hard to say "Oh this is so cool" - or "Forget it".


?  What I’m suggesting does nothing to diminish that.  It just makes for an
> efficient way to have both MNA and RAF in the same packet.  It allows us to
> carry both hop-specific actions and ubiquitous actions efficiently.
>

Yes I get that. But carrying them together already produces new challenges.
Not that those challenges would not be able to be solved. But at least we
should agree that such integration immediately triggers them.

Of course this is not to say that even if we do not integrate they do not
exist - but on my side I would leave those to the user to prioritize
execution between RFV and ISDs.


I was not suggesting merging documents.  I was suggesting that your
> document become a network action specification.
>
> Having it as a separate feature is a detriment to both, especially when
> both would occur in the same packet. Encoding them together would be lower
> overhead.
>

So I am not seeing any lower byte overhead. But I do see inherent
complexity if one would be to use both.

Kind regards,
Robert