Re: [mpls] Reference Augmented Forwarding - MPLS RAF

[Tony Li <[e-mail]>]

Hi Robert,

>  I’m simply trying to address use cases and requirements.  Yes, it would be much better to have a true understanding, but I have yet to get a clear explanation myself.
> 
> I think this is necessary to make sure what we build will actually work. Some people still believe that you can emulate SONET/SDH/TDM type of containers in IP networks. And they say slice would be channel ID. Unfortunately this is not how IP networks work which I have heard is still surprising to a few folks. Statistical multiplexing concept is still also foreign to them. 


I agree that it would be beneficial and I welcome input. I cannot help educate them.  ;-)


>  There’s another 11 bits in an LSE and it would make more sense to allocate them than to waste them.  As we’ve discussed, there might be a scalability issue and 11 bits might go a long way in improving the range.
> 
> Honestly I can get those 11 bits today with no issue. I only need S bit to be untouched in LSE post RFI so I can have 31 bits today. (Total size I assume is still 4 octets :). 


Agreed.  I think you should.


>> Of course this is not to say that even if we do not integrate they do not exist - but on my side I would leave those to the user to prioritize execution between RFV and ISDs.
> I’m not following you.  If they are not integrated, then the specification xor the implementation is going to define the order of execution, the same as if they are integrated.  The integrated approach would give us lower overhead (e.g. only one SPL).
> 
> Well first you are optimistically assuming there is market need for both :) 


If there is no market need for any of this, then we can all just stop. :)  Yes, I am placing a whole lot of trust in folks who claim that this will be useful.  I would definitely like to hear more from operators who WILL actually use this. Vendors need not chime in.


> Then if there is market need then order of execution should be left to the operator to specify. 


That adds a runtime decision.


> The complexity will be there if both RAF and MNA functions are required.
> 
> Yes. Even within ISD if you put 5 actions there is complexity. 
> 
> Going under ISD is a very very risky business from the perspective of upgrades. Suppose node supports action MNA_1, MNA_2 and RFV. One day some one like to introduce MNA_3. Well till *all* routers are upgraded and enabled to execute MNA_3 the entire ISD may be ignored in best case. Or packet can be dropped the moment MNA_3 is in ISD and packet hits non upgraded box. 


We’ve been talking about carrying per-action capabilities for exactly this purpose.  If a flow aggregate needs action MNA_3, then the PCE computes a path along nodes that are only MNA_3 capable.  This should have zero impact on other flow aggregates.


> And remember RAF specifically targets spots not the entire network to execute additional network functions. 


I got that the first time, no need to keep repeating yourself.


> The added complexity would come from two modifications to the stack vs. one
> 
> Well in the vast majority of my deployment RAF tuple should not be modified anywhere in the network.


It must be inserted at some point.  And if MNA is used, then it must be inserted as well.


> , plus searching for two SPLs in the stack.
> 
> Hmmm didn't you say the other day that each LSR needs to parse the entire stack anyway in search for SPLs ? Remember my comment during the last meeting .. today label stack has no offset so you do not know what it contains till you parse it. Heavy ! 


This is true.  Already happening for EL.


> Life looks simpler if things are integrated.
> 
> See I do not mind integration, but I do have real concern that in the event vendors decide not to support MNA at all - RAF is dead. And to tell you the truth, what I am seeing and hearing in respect to MNA's future is not too promising. Yes - I am sure it can be pushed through IETF, but that's not the point :) 


The future of ANY feature is more about operator demand (i.e., $$$) than anything else.

Tony