Re: [mpls] Reference Augmented Forwarding - MPLS RAF

[Stewart Bryant <[e-mail]>]

> On 26 Apr 2022, at 07:56, Robert Raszuk <[e-mail]> wrote:
> 
> Hi Stewart,
> 
> Yes I have thought about new FEC type as well however more pragmatic solution surfaced. Main reason being that we are no longer at green field with MPLS and what we design MUST work with existing deployments for smooth adoption.

I wonder ho difficult it is to introduce the new FEC along the LSP either though LDP or through the IGP SR style or even PPR style.

Remember that in most cases you want this to operate along the whole of the LSP, and don’t care if it does not operate off the LSP.  There may well need to be a capability check along the LSP in many cases.

My deep concern is that we are using SPLs as an easy fix to introducing features over legacy and ignoring the control plane solutions that are the heart of the MPLS design philosophy.

> 
> Another reason is that today LSPs and constrained LSPs are in vast majority used to hide IP header from core. And that function is done well. So I do not see a compelling reason to replace it with something new - hence natural way to think of hybrid model. Do not break what works well, but add a bit more toppings on it if someone asks. 


> 
> On your last point I am not sure I get it. SPL is base for MNA/MIAD alternative proposal so I assume you have same reservations there. 

Yes, and I am wondering if we are on the right lines by abandoning our traditional anathema towards embedding features in the data plane instead of introducing them through the control plane.

Always good to checkpoint this aspect of a feature before making an irrevocable change,

> 
> Now in terms of opaque vs public identifiers please observe that RFV is fully opaque a domain wide value. Nothing is public about it. It can be dynamically allocated too. So the fact that we recognize RFV with RFI is direct analogy where we use ELI to recognize that EL follows on the stack. Is that your concern or am I misunderstanding point you are making ? 

I like the use of the programmable RFV, and some of us have been wondering what the right scope of the NAI mappings should be. The question is whether RFI needs to be a well known value taking up stack space, or whether it can be a characteristic of the ToS FEC?

- Stewart

> 
> Many thx,
> Robert
> 
> 
> On Tue, 26 Apr 2022 at 08:37, Stewart Bryant <[e-mail] <mailto:[e-mail]>> wrote:
> Interesting idea, and I have also been wondering for a number of reasons whether we were straying too far from the standard call by reference model that underpins MPLS.
> 
> However, if we define a new FEC we do not need an SPL, and save space in the stack since the delivery label is the “SPL” for the network action label.
> 
> The two reasons I am worried about SPLs is firstly loss of generality in a protocol that has peen served so well by the use of opaque identifiers, and the resultant damage to the MPLS data plane security model that the move from opaque to public identifiers introduces. 
> 
> Stewart
> 
> Sent from my iPad
> 
>> On 25 Apr 2022, at 21:34, Robert Raszuk <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> Dear WG,
>> 
>> As we have discussed on the list I am posting a description of an alternative architectural approach on how MPLS data plane can be enhanced/extended to support execution of arbitrary network actions as well as support network programming with minimal extensions to label stack encoding. 
>> 
>> Comments, questions and contributions all very welcome. 
>> 
>> Kind regards,
>> Robert
>> 
>> ---------- Forwarded message ---------
>> From: <[e-mail] <mailto:[e-mail]>>
>> Date: Mon, Apr 25, 2022 at 10:27 PM
>> Subject: New Version Notification for draft-raszuk-mpls-raf-fwk-00.txt
>> To: Robert Raszuk <[e-mail] <mailto:[e-mail]>>
>> 
>> A new version of I-D, draft-raszuk-mpls-raf-fwk-00.txt
>> has been successfully submitted by Robert Raszuk and posted to the
>> IETF repository.
>> 
>> Name:           draft-raszuk-mpls-raf-fwk
>> Revision:       00
>> Title:          Framework of MPLS Reference Augmented Forwarding
>> Document date:  2022-04-25
>> Group:          Individual Submission
>> Pages:          8
>> URL:            https://www.ietf.org/archive/id/draft-raszuk-mpls-raf-fwk-00.txt <https://www.ietf.org/archive/id/draft-raszuk-mpls-raf-fwk-00.txt>
>> Status:         https://datatracker.ietf.org/doc/draft-raszuk-mpls-raf-fwk/ <https://datatracker.ietf.org/doc/draft-raszuk-mpls-raf-fwk/>
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-raszuk-mpls-raf-fwk <https://datatracker.ietf.org/doc/html/draft-raszuk-mpls-raf-fwk>
>> 
>> Abstract:
>>    This document specifies an architectural framework for enabling MPLS
>>    based forwarding with optional reference based packet processing in
>>    transit network elements.
>> 
>> The IETF Secretariat