Re: [mpls] Reference Augmented Forwarding - MPLS RAF

[Robert Raszuk <[e-mail]>]

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