Re: [mpls] Reference Augmented Forwarding - MPLS RAF

[John E Drake <[e-mail]>]

Hi,

This makes a lot of sense to me, particularly since it allows multiple scopes to be encoded in a single NAS and enables user-defined network actions.

Yours Irrespectively,

John



Juniper Business Use Only
From: Tony Li <[e-mail]> On Behalf Of Tony Li
Sent: Friday, April 29, 2022 10:28 AM
To: Robert Raszuk <[e-mail]>
Cc: John E Drake <[e-mail]>; Haoyu Song <[e-mail]>; mpls <[e-mail]>; Jeff Tantsura <[e-mail]>; Kireeti Kompella <[e-mail]>; Stewart Bryant <[e-mail]>; Tarek Saad <[e-mail]>; [e-mail]
Subject: Re: Reference Augmented Forwarding - MPLS RAF

[External Email. Be cautious of content]


Hi Robert,


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 ?


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.
- 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.
- Some combination of the above.
- 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.


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.


Agreed.


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.


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.


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 ?


Virtual routers go hand in hand with VPNs and virtual topology.


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


No, I'm suggesting that you could expand RFV to 31 bits.


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.


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


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.


That is not without merit.


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.


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.

Tony