Re: [mpls] Reference Augmented Forwarding - MPLS RAF

[Robert Raszuk <[e-mail]>]

Hi Stewart,

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

For LDP signalled LSPs with ordered control or RSVP-TE LSPs this would be
trivial extension. With domain wide labels much more difficult as transit
nodes just reflood IGP advertisements or the egress or segment endpoints.

Remember that in most cases you want this to operate along the whole of the
> LSP,
>

Well I do not think so. IMO network actions will be enabled on very few
selective transit/service nodes. So as paramount design principle to me is
to make sure that existing transit nodes must work with this new model with
no code change.

If we ignore that motivation we could explore other options, but even if so
that would seems to me like a parallel track solution.

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

Well as you see Reference Augmented Forwarding is actually a full control
plane solution. The signalling reference in the packet being separate from
forwarding label value itself as mentioned is a design choice based on few
points:

* backwards compatibility to deployed MPLS transport

* compatibility with hop by hop or domain wide labels

* decoupling network actions or network programming control plane
(configuration or pub-sub dist.) from forwarding data plane (yes I do think
this is a feature not a bug)

* scalable (no label explosion) for selective execution chains

* keep label stack of fixed length with max 8 octet growth

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,
>


Exactly spot on. And that is actually what motivated me the most to speak
up and to write this draft. I do think too many folks got side blinded by
notion of source routing and instead of looking at the problem holistically
with ability to think outside of the box just try to copy cat the SRv6
model to fit MPLS architecture.

Not a good idea IMHO for various reasons.

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?
>

Well maybe we could have both.

Leave RFV as is and offer two options .. new FEC (if we figure out that
domain wide labels is doable in new FEC model  as well as offer bSPL marker
as a backwards compatibility solution. Market can decide. From a data plane
perspective both bSPL  marker for RFV or new FEC as marker or as carrier of
RFV - do not pose any major surgery.

Thx,
Robert