Re: [mpls] Reference Augmented Forwarding - MPLS RAF

[Robert Raszuk <[e-mail]>]

Yes right.

But what you said sounded like RAF is the same as
draft-song-ippm-postcard-based-telemetry/
<https://datatracker.ietf.org/doc/draft-song-ippm-postcard-based-telemetry/>
which
I corrected as it is too coarse of the statement.

Thx,
R.

On Wed, 27 Apr 2022 at 12:02, Tianran Zhou <[e-mail]> wrote:

> Hi Robert,
>
> I may not correct. Here, “similar”, I mean detailed instructions are not
> carried in the data plane, but preconfigured on the devices.
>
> Best,
>
> Tianran
>
>
>
> *From:* Robert Raszuk [mailto:[e-mail]]
> *Sent:* Wednesday, April 27, 2022 5:57 PM
> *To:* Tianran Zhou <[e-mail]>
> *Cc:* Aijun Wang <[e-mail]>; Tony Li <[e-mail]>;
> mpls <[e-mail]>
> *Subject:* Re: [mpls] Reference Augmented Forwarding - MPLS RAF
>
>
>
> 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
>
>
>
>