Re: Reference based Routing (RbR)

[Robert Raszuk <[e-mail]>]

Hi Brian,

> It doesn't seem to need any 6MAN action whatever.

True - unless we collectively would decide to carry the reference in the
new RH.

Otherwise it is not even Routing Area topic either :)

See IETF is great to standardize new protocol extensions and add
complexity.

But when a lot of new functionality could be enabled with
existing protocols if vendors would agree to support it my personal
observation is that it has no good process to follow.

Best,
R.

PS. Encoding a reference into MPLS label could be an option if given domain
already uses MPLS. That comes with cost and complexity (running LDP between
all network elements or SR-MPLS). For now let's assume domain is not
enabled for using MPLS transport.


On Sun, May 24, 2020 at 10:36 PM Brian E Carpenter <
[e-mail]> wrote:

> Hi Tony,
>
> On 25-May-20 06:10, [e-mail] wrote:
> >
> > Hi Robert,
> >
> >> If I would insert a reference into flow label space I am afraid I would
> lose the current flow label functionality which perhaps in some cases may
> not be desired.
> >
> >
> > Is someone actually using the flow label?  As far as I know it’s wholly
> unused.
>
> It's set according to RFC 6437 by all modern Linux and Windows hosts for
> both TCP and UDP traffic. To what extent it's being used for load balancing
> is hard to tell, but
> it isn't free for traffic engineering.
>
> My own reaction to Robert's proposal is that it did indeed sound like a
> description of a way to use MPLS labels.
>
> <snip>
>
> > Changing the semantics of any part of the address space may require more
> semantic and pragmatic changes than would be necessary via other approaches.
>
> Overloading part of the interface identifier with local semantics is an
> obvious temptation, and really no more shocking than RFC8273. I am much
> more bothered by proposals to encode semantics in high order address bits.
>
> But anyway... routing area topic? It doesn't seem to need any 6MAN action
> whatever.
>
>    Brian
>
>