Re: [mpls] Reference Augmented Forwarding - MPLS RAF

[Robert Raszuk <[e-mail]>]

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.

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.

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 ?

Many thx,
Robert


On Tue, 26 Apr 2022 at 08:37, Stewart Bryant <[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]> 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]>
> 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]>
>
> 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
> Status:
> https://datatracker.ietf.org/doc/draft-raszuk-mpls-raf-fwk/
> Htmlized:
> 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
>
>