Re: [mpls] Reference Augmented Forwarding - MPLS RAF

[Tony Li <[e-mail]>]

Hi Robert,


> - One might have a mapping from GISS to FlexAlgo topology.
> 
> Ok. And do you expect to have how many parallel flex-algo topologies running in a network. And even that is not real question,. Real question is how one such topology differ from the other to get into 2^10 slices or even let's go lower and say 2^8 ? 


Again, I’m no expert on slicing or on 5G.  I have no idea what they have up their sleeves.  FlexAlgo does support 2^7 topologies. I have no idea how anyone could manage that, even with extensive automation, but the architectural capability is there.


> - One might want to ensure that package for a given slice only leaves the underlay on an exit link for the same slice. 
>   This would be an authentication check only on the exit router.
> 
> Ok. Don't we have EPE for this ? Or are you saying that we do not trust EPE and want to just double check ?


Again, I’m not an expert on this area, 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.


> - One might just use GISS as ’security theatre’ and carry overhead in every packet without any check. All cost, no benefit.
> 
> :)


If it’s not clear, this is what I’m betting on.  :)


> No, I’m suggesting that you could expand RFV to 31 bits.
> 
> I am not sure I see a need. For my view of practical use cases even 20 bits is more then enough.


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


> But you said RFV would be a parameter to an MNA action - correct ? 


Yes.


> Where would this action be placed ? ISD after top label only ? Any ISD ? Any ISD or PSD ? 


ISD would make sense to me.


> Then where would the parameter sit ? Immediately behind the action ? Somewhere else ? 
> 
> Would action be in ISD and parameters in PSD ? 
> 
> That's why I am skeptical and till I undersand those details it is very hard to say "Oh this is so cool" - or "Forget it". 


To be very clear: the network action indicator for ‘select’ would be encoded as part of the indicators in the NAS.  The details of the encoding are left to the solution.  The RFV would then be in the ISD. I see no need to put anything in the PSD.


> ?  What I’m suggesting does nothing to diminish that.  It just makes for an efficient way to have both MNA and RAF in the same packet.  It allows us to carry both hop-specific actions and ubiquitous actions efficiently.
> 
> Yes I get that. But carrying them together already produces new challenges. Not that those challenges would not be able to be solved. But at least we should agree that such integration immediately triggers them. 


Agreed, it’s not the same.


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


> I was not suggesting merging documents.  I was suggesting that your document become a network action specification.
> 
> Having it as a separate feature is a detriment to both, especially when both would occur in the same packet. Encoding them together would be lower overhead.
> 
> So I am not seeing any lower byte overhead. But I do see inherent complexity if one would be to use both.


The complexity will be there if both RAF and MNA functions are required. The lower overhead is from a single SPL rather than 2. The added complexity would come from two modifications to the stack vs. one, plus searching for two SPLs in the stack.

Life looks simpler if things are integrated.

T