Re: [mpls] Reference Augmented Forwarding - MPLS RAF

[Robert Raszuk <[e-mail]>]

Hi,


> I think the following proposal shares the similar idea as this RAF
> proposal.
>

No. RAF is much broader than that. OAM handling is just one element of it.

Yes RAF can use the OAM handling as proposed in the draft below as is.

Thx,
R.



> https://datatracker.ietf.org/doc/draft-song-ippm-postcard-based-telemetry/
>
>
>
> It could work well with RAF. Just use the label to indicate the postcard
> behavior, IMO.
>
>
>
> Cheers,
>
> Tianran
>
>
>
> *From:* mpls [mailto:[e-mail]] *On Behalf Of *Aijun Wang
> *Sent:* Wednesday, April 27, 2022 3:56 PM
> *To:* 'Robert Raszuk' <[e-mail]>; 'Tony Li' <[e-mail]>
> *Cc:* 'mpls' <[e-mail]>
> *Subject:* Re: [mpls] Reference Augmented Forwarding - MPLS RAF
>
>
>
> 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
>
>
>