Re: [mpls] Reference Augmented Forwarding - MPLS RAF

[Robert Raszuk <[e-mail]>]

Hi Tony,

GISS is the Global Identifier for Slice Selector.  Basically, it’s a slice
> index.
>

So since we are again on the "slice" topic can you tell me from edge and
core routers points of view what is the real forwarding difference from the
way one slice is handled vs another 2^10 (I saw such numbers on this list)
slices ?


> But for slices I would rather take a network wide view, focus on slice to
> slice forwarding difference and build end to end slice plane - not a hop by
> hop classification based mapping. But this is just me.
>
> That is exactly the intent.  To do that, you need some way of identifying
> the slice that the packet belongs to.
>


My point is that identifying slice hop by hop is not enough if you want to
treat slices seriously. End to end TE should be applied of some form. It
can be SR-MPLS, it can be flex-algo or it can be MT/MI.

Just marking packets and recognizing that mark hop by hop does not make the
forwarding unique (and if it does again let's understand what is the unique
part). I saw somewhere that slice is just about separation - Well we have
L3VPN (or even L2VPNs) which do separation in a pretty decent way. But P
routers are not involved.

Is the idea that we are yet one more time resurrecting the concept of
Virtual Routers this time boldly going into 2^10 scale on each P node ?


> I agree that RAF and MNA as defined are complementary and that an
> alternate way of approaching this is to have RAF be a network action in and
> of itself.  It would be carried inside of the NAS and the RFV would then
> become ancillary data for the function.  The default operation for any RFV
> value would then be NOP and the management and/or control plane could
> install non-default actions as necessary.  I would propose that this
> network action be called ’select’.
>
> Thoughts?
>

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

Yes I get that the degenerated case of ISD with meaning of actions
programmed by control/mgmt could pretend to be functionally similar to RAF.
But I defined RAF to offer new network programming not to redo what today
already is deployed.

To me honestly speaking MNA is way too complex, has too many moving parts
for practically questionable use case(s). I am afraid that MNA instead of
fueling MPLS to new altitudes can have exactly the opposite effect.

So for now I would like to keep it as a separate document. The cost of
doing so is by asking for a new bSPL type. And if that would be denied then
perhaps I am cool using eSPL and burning one more LSE for it. After all,
you are apparently planning on the same overhead if RFV would be used as
ancillary data.

Kind regards,
Robert
















>
> Tony
>
>
>
>
>
>