Re: [mpls] Reference Augmented Forwarding - MPLS RAF

[Aijun Wang <[e-mail]>]

Hi, Robert:

How to add additional data to accomplish the In-situ OAM similar function based on your proposal?

If not, what’s the difference to apply the traffic policy via the management from your proposal?

 

Best Regards

 

Aijun Wang

China Telecom

 

From: [e-mail] <[e-mail]> On Behalf Of Robert Raszuk
Sent: Wednesday, April 27, 2022 7:28 AM
To: Tony Li <[e-mail]>
Cc: mpls <[e-mail]>
Subject: Re: [mpls] Reference Augmented Forwarding - MPLS RAF

 

Hi Tony,

 

- I like the acronym. :-)  We need to find a Spitfire somewhere in the proposal. Or Snoopy.

 

Not a big challenge :)  My original idea was Forwarding Behaviour Indicator (FBI), but was a bit worried about using it for perhaps obvious reasons. 

 

- This doesn’t really seem like a Framework document. It’s a complete proposal, architecture to details.

 

Well ... the reason I added some details was to highlight the architectural principles. They are in no way exhaustive. Lots of details especially in distribution of network actions needs to be defined in a separate document. Then perhaps we could add a new document as an extension to DROID. 

 

- You say that this is an implicit model. I disagree. It is very much explicit. It explicitly shifts the responsibility for communicating network actions to the control plane.

 

Well yes. I mean implicit from a data plane perspective. But I am willing to call it with what WG recommends. 

 

- Section 2.1: Your definition of a Network Action says that it may not affect packet switching. That seems surprising. Wouldn’t we want the flexibility to make the packet switch differently? In the very next sentence you say that an action may affect forwarding. I’m pretty sure that I’m not following the distinction that you’re making here.  Could you please expound?

 

Ah .. ok I will clarify in the draft here. By not affecting switching I mean that the packet may only trigger some actions which are orthogonal to switching decisions or any packet processing (as departure from "normal"). Those would be for example triggers to generate OAM postcards. Trigger to generate some local traps. Trigger to generate any form of streaming telemetry. The list goes on and on. 

 

Of course the other category is to purposely affect switching/forwarding/routing/queuing decisions - this is very true. 

 

- You mention that network actions are distributed by configuration.  Could this be generalized to be the management plane?

 

I was thinking about it. The only reason I did not call it that way that I did not want to preclude IGP extensions to flood it. Or flowspec v2. I was also not sure if DROID would be classified as management plane ? 

 

But in general yes stating management plane instead of configuration is great even if we would include other options to push those instructions/mappings. 

 

- Isn’t a RFV a label?  It’s occupying 20 bits in the label stack, in the place where there would be a label.  Should we call it a Reference Forwarding Label (RFL)?  

 

It is. I am ok with renaming it as such. The only little detail here that within RFV LSE we could also use TTL field for some meaning. That would no longer be label. However with your suggestion we could nicely make it cristal clear - RFL + RFV (the latter to mean only the portion of 8 bits of TTL). 

 

Terminology is all open for such great suggestions. I wrote it up to trigger discussion about alternative model :). 

 

- Why have the RFI at all?  Why not just explicitly allocate RFV labels that encode both forwarding plus actions?

 

Doable in theory but there are multiple reasons why I think this would be a bad idea. Quote from my note to Stewart: 

 

" The signalling reference in the packet being separate from forwarding label value itself as mentioned is a design choice based on few points: 

 

* backwards compatibility to deployed MPLS transport 

 

* compatibility with hop by hop or domain wide labels

 

* decoupling network actions or network programming control plane (configuration or pub-sub dist.) from forwarding data plane (yes I do think this is a feature not a bug) 

 

* scalable (no label explosion) for selective execution chains

 

* keep label stack of fixed length with max 8 octet growth

 

+ few new points: 

 

Moreover what significantly helps (and what perhaps is not very clear from the draft) is that RV mapping has *local* significance. That means each transit node may act differently on the same RF value. 

 

So I look at RFV as a marker for groups of uniquely treatable groups of flows, not as expressions of verbatim chains of actions. 

 

Moreover nothing prevent operator to structure RFV. Say you have 5 very often used actions. So you could hijack first 5 bits of that label to turn them into a bitfield. Last if one would ever get that he needs more then 2^20 groups of flows markers for different treatment there is always option to add one more RFV' and instead of sending RFI+RFV send RFI+RFV+RFV' 

 

- It seems like you could just reserve the TC and TTL fields in both LSEs.

 

Clearly not in both. I want to support the SDN case where RFI is still top of the stack. But in general yes as you see above this is considered. TC bits in RFV I left for now alone. 

 

- I’m not sure I see the point in specifying a TLV encoding without any understanding of what it’s carried in.

 

Right. This was just an illustration. I have some vision why TLV format there may be useful but this can all be flatten too. Especially that this can be pushed by mgmt too. 

 

- I have a serious concern about this approach for short-lived flows or single packet exchanges.  In these cases, the control plane effort to establish forwarding state may well exceed the intended usage. For example, suppose that we want an IOAM function such as a ping.  It seems like we would need to establish state end-to-end before we sent the ping request.  That might require many milliseconds and the might only be used for one packet.  Then I presume that there would be some mechanism to remove the state. For long-lived flows, your proposal seems rational.

 

That is not at all how I envision this would work. 

 

State programming is NOT to be triggered by flow appearance. State should be preconfigured before ingress would mark any group of flows for specific treatment. 

 

I do not see this would be of any concern. So even for short lived flows this should be pre-programmed. Note by notion of "pre-programming" network elements may not need to put all into FIB level. Some rarely used mappings can be cached then moved to FIB upon hit. 

 

- Forwarding state is a serious concern. How does this scale?

 

See above. 

 

- You write:

 

   If LSP is not setup and the network uses the concept of SDN
   based path computation it can be preset as topmost LSE.

  How does this work?  Are you assuming that a controller will push a stack on top of this?

 

Nope. 

 

Ingress marks a groups of flows with a single RFV label. 

 

That label is mapped to different switching action at each node it is to traverse. Just a bit like OF (sigh :)

 

Note that as stated above and what perhas is a bit not exposed in the draft - reference to action mapping is local to the receiver (ie. transit node). 

 

-If the topmost label is popped, then the RFI/RFV come to the top of the stack. Are they discarded?

 

As I mentioned egress will need to understand it and discard (perhaps using TC bits or checking TTL. 

 

- You write:

 

   If a node is enabled to perform additional actions on the
   packets it should leave the RFI/RFV tuple as received immediately
   after the top label swap on the stack.

   I don’t understand why you have the word ‘swap’ in this sentence.  

 

Ahhh basic LDP label swapping - as opposed to global label no swap :)

 

Many many thax Tony for great comments !!!

 

Kind regards,

Robert