Re: [mpls] Reference Augmented Forwarding - MPLS RAF

[Tarek Saad <[e-mail]>]

Hi Robert,

Inline.. [TS3] this time.

From: Robert Raszuk <[e-mail]>
Date: Thursday, April 28, 2022 at 2:54 PM
To: Tarek Saad <[e-mail]>
Cc: mpls <[e-mail]>, Tony Li <[e-mail]>, Haoyu Song <[e-mail]>, Jeff Tantsura <[e-mail]>, John E Drake <[e-mail]>, Kireeti Kompella <[e-mail]>, Stewart Bryant <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Reference Augmented Forwarding - MPLS RAF
Hi Tarek,

/* Editorial nit - Do you really need to write using such huge font ? */
[TS]: 😊 in my email editor your font and mine are of same size!!  – hope it’s not too annoying on your side. See my screen capture from my editor below:
[cid:image001.png@01D85B16.62793B70]


[TS2]: I’d think it is an important requirement as I’d venture to say SR-MPLS is widely deployed today.


SR-MPLS I have seen today is used to build LSP instead of using LDP. Extra traffic anchors from what I have seen are sporadic.

Said this there is no magic - If you have segment endpoints between ingress and egress and you pop label ISD or RFI will be exposed.

So you need to handle it.

>> I hope you are not endorsing to have identical copy of ISD after each SR-MPLS label ...
[TS3]: I am not, and in fact it is one reason why I suspect transit nodes just copying the previous segment RFV won’t cut it. There is a usecase where the ingress may associate each SR segment with different RFV.

[TS2]: In SR, every prefix/algo is usually assigned a global index (a label is derived from SRGB on every node). To indicate the presence of the RAF in a separate label (per prefix) will require another separate index/label for each node/prefix for every SR (flex)algo. For network slicing, this even scales further to an index/label per node/prefix for every Network Resource Partition (NRP) in each algorithm – which is a scale challenge.

Not everyone will be using all of the above at the same time. Again this is just topic which I added as an option. If given operator does not need it he may not use it.

[TS3]: one of the usecases that MNA will tackle is realizing network slicing with NRPs and resource-aware SR SIDs.


Actually not. That data comes via mgmt/control plane custom to each segment endpoint and single RAV is used.

[TS2]: this is per path state in the control plane – which people argue don’t scale as good. It may be desirable to eliminate per path state on transit nodes – hence carrying data in the packet.


No it is not literally per path. You can have 1000 TE paths using the same RFV value. For example you want to trigger OAM postcard from each node.
[TS3]: Yet for other applications (like delay budgeted ones), the delay budget is for each path (and for each segment or transit hop on that path). Signaling such delay budget on that path will make it a per path state.

Regards,
Tarek

It is in fact much less state then RSVP-TE :)  It all depends what operator wishes the network to do and where with the packets traversing it.

Cheers,
R.