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.

Reply via email to