On 17 September 2020 11:05:24 CEST, Saku Ytti <s...@ytti.fi> wrote:
>On Thu, 17 Sep 2020 at 11:03, James Bensley <jwbensley+na...@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.
Nope, we have the same understanding. But the email I was responding to was
talking about using MPLSoUDP for service label encapsulation *only*, not
transport & services labels:
>> If you want an IPv6 underlay for a network offering VPN services
>
> And what's wrong again with MPLS over UDP to accomplish the very same with
> simplicity ?
>
> MPLS - just a demux label to a VRF/CE
> UDP with IPv6 header plain and simple
>
> + minor benefit: you get all of this with zero change to shipping hardware
> and software ... Why do we need to go via decks of SRm6 slides and new wave
> of protocols extensions ???
Cheers,
James.
