Re: [mpls] Reference Augmented Forwarding - MPLS RAF

[Tony Li <[e-mail]>]

Hi Robert,


> I was assuming that you were supporting all of the actions that MNA is planning on supporting.  My bad. What are you supporting?
> 
> My goal was to support selective (in few network nodes) processing on packets, ideally all operator's defined -  more or less like in SFC manner, but OAM postcard, trace with separate responses, . 
> 
> I noticed that where MNA and RAF differ it was not only in the model of data plane vs control plane action messaging. Fundamentally I was not really focusing on supporting anything which needs to be executed on all nodes. 
> 
> Where support of ECMP or slices needs to be executed on all LSRs my assumption was (and still is) that is it much better to use existing encoding for it. 
> 
> So I do admit I wrote this draft as an alternative to MNA. However now after our discussion on the list (for good or for bad :) I think we have different objectives and honestly MNA and RAF are (or can be) complimentary and independent. 


I concur partially.  See below...


> But the same scaling question exists even if you’re just doing GISS.  Let’s assume that I need 8 slices in my network.  Do I need 8 RSVs?
> 
> Sorry I do not know what is GISS ... geographic information systems  ? But yes if you really want to classify packets into a slice at hop you need to carry it explicitly (in ISD via RFV pointer or embed it somewhere in the stack). 


GISS is the Global Identifier for Slice Selector.  Basically, it’s a slice index.


> But for slices I would rather take a network wide view, focus on slice to slice forwarding difference and build end to end slice plane - not a hop by hop classification based mapping. But this is just me. 


That is exactly the intent.  To do that, you need some way of identifying the slice that the packet belongs to.  


I agree that RAF and MNA as defined are complementary and that an alternate way of approaching this is to have RAF be a network action in and of itself.  It would be carried inside of the NAS and the RFV would then become ancillary data for the function.  The default operation for any RFV value would then be NOP and the management and/or control plane could install non-default actions as necessary.  I would propose that this network action be called ’select’. 

Thoughts?

Tony