SRv6 Capable NOS and Devices -> MPLS instead?

scott surfer at
Sat Jan 15 23:25:28 UTC 2022

On 1/15/2022 9:16 AM, Raymond Burkholder wrote:
> On 1/15/22 10:22 AM, Colton Conor wrote:
>> True, but in general MPLS is more costly. It's available on limited
>> devices, from limited vendors. Infact, many of these vendors, like
>> Extreme, charge you if you want to enable MPLS features on a box.
> And in this discussion group, when MPLS is mentioned, does that 
> include VPLS?  Or do operators simply use MPLS and manually bang up 
> the various required point-to-point links?  Or is there a better way 
> to do this?
> For example, Free Range Routing can do do MPLS, but I don't think it 
> has a construct for VPLS (joining more than two sites together).


MPLS has services that run on the top of it.  VPLS is one of those 
services.  The other two main services are VPRN and pseudowires.  First 
the MPLS is configured (LSPs between nodes) and then the services are 
configured that run on top of MPLS.


>> On Thu, Jan 13, 2022 at 3:11 AM Saku Ytti <saku at> wrote:
>>> On Thu, 13 Jan 2022 at 00:31, Colton Conor <colton.conor at> 
>>> wrote:
>>>> I agree it seems like MPLS is still the gold standard, but ideally I
>>>> would only want to have costly, MPLS devices on the edge, only where
>>>> needed. The core and transport devices I would love to be able to use
>>>> generic IPv6 enabled switches, that don't need to support LDP. Low end
>>>> switches from premium vendors, like Juniper's  EX2200 - EX3400 don't
>>>> support LDP for example.
>>> It is utter fallacy that MPLS is costly, MPLS is systematically and
>>> fundamentally cheaper than IPv4 (and of course IPv6 costs more than
>>> IPv4).
>>> However if this doesn't reflect your day-to-day reality, then you can
>>> always do MPLSoGRE, so that core does not need more than IP. So in no
>>> scenario is this narrative justification for hiding MPLS headers
>>> inside IP headers, which is expensive and complex, systematically and
>>> fundamentally.
>>> -- 
>>>    ++ytti

More information about the NANOG mailing list