SRm6 (was:SRv6)

Thu Sep 17 09:15:59 UTC 2020

Spot on.

And on the point of protection ... in all cases it is orthogonal to the
service itself. If you want to use it you enable it regardless if your
packet's transport is IPv4, IPv6, MPLS or any SR flavor.

Sure if you need to traffic engineer your services some form of path
control is required. It can be stack of SIDs, it can be pre-signalled paths
or it can be pure encap-decap on selected anchor points. Your network -
your choice.

Thx,
R.

On Thu, Sep 17, 2020 at 11:07 AM Saku Ytti <saku at ytti.fi> wrote:

> On Thu, 17 Sep 2020 at 11:03, James Bensley <jwbensley+nanog at gmail.com>
> wrote:
>
> > MPLSoUDP lacks transport engineering features  like explicit paths, FRR
> LFA and FRR rLFA, assuming only a single IP header is used for the
> transport abstraction [1]. If you want stuff like TI-LFA (I assume this is
> supported in SRm6 and SRv6, but I'm not familiar with these, sorry if that
> is a false assumption) you need additional transport headers or a stack of
> MPLS labels encapped in the UDP header and then you're back to square one.
>
> One of us has confusion about what MPLSoUDP is. I don't run it, so might
> be me.
>
> SPORT == Entropy (so non-cooperating transit can balance)
> DPORT == 6635 (NOT label)
> Payload = MPLS label(s)
>
> Whatever MPLS can do MPLSoUDP can, by definition, do. It is just
> another MPLS point-to-point adjacency after the MPLSoUDP
> abstraction/tunnel.
>
> --
>   ++ytti
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200917/94ddf033/attachment.html>