Re: [mpls] Reference Augmented Forwarding - MPLS RAF

[Tony Li <[e-mail]>]

Hi Robert,

Thank you for documenting your proposal.  Some comments for you:

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

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

- 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.

- 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?

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

- 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)?  

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

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

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

- 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.

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

- 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?

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

- 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.  


Regards,
Tony