On Wed, 12 Jan 2022 at 00:00, Adam Thompson <athompson@merlin.mb.ca> wrote:

My question is, why do you think you need Segment Routing at all? Is your network so enormously large and/or complex that IS-IS (and/or MPLS-TE) isn't capable of handling it? So far, SR looks like a solution in search of a problem, at least to me.

SR is terrific, SRv6 is snake-oil. Everyone needs some type of tunnelling in most modern applications of the network. maybe for pseudowires, repair, l3 vpns, traffic engineering or just removing state and signalling from backbone. Signalling labels via IGP is obviously better than via LDP. -- ++ytti

On Wed, 12 Jan 2022 at 18:20, <aaron1@gvtc.com> wrote:

Like ytti (saku) mentioned, with SR/SPRING the IGP is finally carrying the Label/Sid, so we no longer need a label distribution mechanism running alongside the IGP (don't need LDP or RSVP). And for SRv6 vice SR-MPLS, the SID is now the IPv6 address, and not the MPLS Label. So we don't even need MPLS, but can accomplish network virtualization using a pure IPv6 core. Reminds me of Cell Mode MPLS vs Frame Mode MPLS... whereas the ATM Cell header VPI/VCI was repurposed as the MPLS label, until we went with straight MPLS shim headers.

No SRv6 is MPLS labeling where label is carried inside IP instead before the IP header. Layering violation which increases complexity and cost for no other purpose except dishonest marketing about 'it is IP, you already understand it, MPLS is hard'. -- ++ytti

Thus spake Sander Steffann (sander@steffann.nl) on Wed, Jan 12, 2022 at 06:21:25PM +0100:

Hi,

...

No SRv6 is MPLS labeling where label is carried inside IP instead before the IP header. Layering violation which increases complexity and cost for no other purpose except dishonest marketing about 'it is IP, you already understand it, MPLS is hard'.

What worries me more is the opportunity for adversaries to inject SRv6 packets. MPLS is not enabled by default on most router interfaces, so an adversary would have to have access to an interface where MPLS processing is explicitly enabled. IPv6 packet processing on the other hand… Unless an operator has airtight protection on every interface to block unwanted SRv6 headers I see some interesting opportunities to cause havoc :)

You are not alone, see for example the thread at https://mailarchive.ietf.org/arch/msg/v6ops/GbWiie-bjQ_Bp1JKB1PlDh_fPdc/ this is more pronounced with respect to the various SRv6 compression scheme proposals. Dale

Hi Randy,

this is quite true, and a serious issue. but it has a good side. if you run an ipv6 enebled network, you can deploy srv6 without enabling srv6 everywhere, only at the marking encaps or embed) points. nice for partial and/or incremental deployment.

Yep, that's what I like about it! But I haven't figured out a way to mitigate the risks. Easy deployment == easy abuse it seems :( Cheers, Sander

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. MPLS switches are very expensive compared to enterprise switches. On Wed, Jan 12, 2022 at 1:09 AM Mark Tinka <mark@tinka.africa> wrote:

On 1/11/22 17:16, Colton Conor wrote:

...

Has anyone deployed this new technology?

I have heard of a network in Uganda that is running it.

The rest I've heard of are either in the lab, or some portions of their network under testing.

...

If building a greenfield regional ISP network, would SRv6 be a requirement?

Nope! It's a problem looking for a problem.

...

My understanding is that because it's using IPv6 in the dataplane, not all devices have to have SRv6 enabled. The in-between core devices just have to support IPv6, but not necessarily support SRv6. This is much different than traditional MPLS networks today where all devices have to support MPLS/LDP correct?

You'd be hard-pressed to find anything that will help you generate revenue that does not come with MPLS baked into the chip and code.

Do you want to take the chance of where and when SRv6 may or may not be needed?

SRv6 is Cisco trying to create a market for a problem that does not exist. In the process, all other vendors are forced to waste tons of money and time to stay in the game, when they could be fixing real problems and adding real value.

Don't fall for the trap. Vote with your wallet, and feet. We did.

Mark.

On Thu, 13 Jan 2022 at 00:31, Colton Conor <colton.conor@gmail.com> 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

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).

On Thu, Jan 13, 2022 at 3:11 AM Saku Ytti <saku@ytti.fi> wrote:

...

On Thu, 13 Jan 2022 at 00:31, Colton Conor <colton.conor@gmail.com> 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

On 1/15/2022 9:16 AM, Raymond Burkholder 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

On 1/15/22 10:22 AM, Colton Conor wrote: 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. scott

...

On Thu, Jan 13, 2022 at 3:11 AM Saku Ytti <saku@ytti.fi> wrote:

...

On Thu, 13 Jan 2022 at 00:31, Colton Conor <colton.conor@gmail.com> 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

+1 Mark There’s no modern silicon that doesn’t support MPLS (and is capable of imposing at least 3 labels). There’s 0 additional price for vendors to enable MPLS on their devices. The rest is subject to vendors’ licensing and is completely artificial. SR-MPLS uses MPLS data-plane and requires no changes to silicon, since head-end might be required to push more labels (TE, BSIDs, services)one needs to pay attention - (RFC8491/8476) allow signaling of MSD (maximum SID depth) if centralized controller/PCE is used for path computation. LDP after all the years of bug fixing is still a crappy protocol, moving to SR-MPLS makes all the sense. Cheers, Jeff

On Jan 15, 2022, at 11:50, Mark Tinka <mark@tinka.africa> wrote:



...

On 1/15/22 19:22, 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.

Well, I don't entirely agree.

Pretty much all chips shipping now, either custom or merchant silicon, will support MPLS. Whether the vendor chooses to implement it in code or not is a whole other matter.

If you need MPLS, chances are you can afford it. If you don't, then you don't have to worry about it.

For Extreme, are you referring to before or after they picked up Brocade?

There is MPLS available in a number of cheap software suites. Even Mikrotik provides MPLS support. Whether it works or not, I can't tell you.

VyOS supports is too. Whether it works or not, I can't tell you.

But I think we are long past the days of "MPLS is expensive".

Mark.

On 1/17/22 03:52, Colton Conor wrote:

I agree that pretty much all the chipsets and asics out there today support MPLS, but it's the vendor and NOS that decides whether to enable it or not, or charge more for it.

That has been the case since MPLS debuted.

Example, Junipers EX4600, QFX5100 and ACX5048 all have the same Broadcom Trident II+ ASIC inside. One supports full MPLS features (ACX), while the other is limited (QFX), and then the EX is even more limited. . Only difference is what Juniper has enabled or disabled in software to my knowledge. All 3 run JUNOS, just different flavors.

I don't see anything wrong with that. As with any business, different products provide different functionality, and as such, come with a different price. You can't expect Cessna's turboprops to fly you 16hrs between two points, non-stop, just because it is an aeroplane. Juniper are targeting different markets and use-cases with their switches vs. their routers. To expect them to provide the same degree of MPLS capability at both ends of the spectrum is unreasonable. I'm certain that in your business, you have different products, as well, that satisfy different types of customers at different price points, with differing value delivery.

Mikrotik's MPLS stack is quite limited, but I hope that will change soon in version 7 that was just released. Honestly hoping that Mikrotik kicks half these vendors in the nuts with everything they are implementing in v7 with the new linux kernel and a development team that is 3x as large. 100G switches are coming soon from them with Marvell ASICs

I actually think Mikrotik should maintain their model. It works for them, and their customer base. It's terrible for support, but you also aren't paying through the nose, and the boxes do what they generally claim to do. I'd rather they did not try to take on the traditional vendors. That pond is already murky as it is.

VyOS doesn't run on any ASIC based systems to my knowledge, so its just a software router.

My point was MPLS is available, even on x86 platforms with open source code. You don't have to pay tons of money for it to get it anymore. Of course, if you want to run it at scale, there are other considerations beyond just the MPLS code itself, as you know.

Extreme charges extra to enable MPLS in their SLX lineup.

High-end IP routing features (which includes MPLS) have always attracted additional costs on what are meant to be Layer 2/3 switches.

Ciena, Ribbon, and others do the same.

Also Tejas, Infinera, Xtera, e.t.c., all "claim" MPLS support, but that's not their bread & butter. So yes, along with the priviledge of it being terribly implemented, you get the pleasure of paying extra for it too, with the optical vendors. Mark.

Isn't the argument here that if it's in most chip sets already it might reasonably be expected to be a standard low end feature by now, along with IPv6?

That it isn't may be why people are open to SRv6 (I'm assuming some are based on this discussion) - if they have to pay extra they only want to do so where they are generating revenue from it, the end points.

HW doing IPv6 does not imply HW being able to do SRv6. SRv6 is not IPV6, SRv6 is MPLS embedded in (HW) complex way in EH. Heck, EH is specified in such a way that no HW device is technically IPv6 capable. What happens when you stack EH headers is question mark, some devices revert to crawl (Nokia FP), some devices drop packet in HW after it sees more than N ER (Juniper Trio). And how does that imply devices capability to find L4 headers and honour ECMP, ACL, QOS is a question mark. -- ++ytti

On Sat, 15 Jan 2022 at 19:22, Colton Conor <colton.conor@gmail.com> 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

Marketing, not fundamentals. DC people are driving demand for VXLAN and SRv6, because they assume MPLS is something scary and complex. So vendors implement something scary and complex to appease DC people. I'm sure in some years to the future, DC people will re-invent MPLS to simplify their stack. -- ++ytti

Hey Sabri, Eventually they have implemented everything ;-) Arista was a really special case, routing stack they acquired (NextHop) had no mpls (quite some time ago), 90% of their revenue was coming from IP only networks. Life is good, MS is treating me well :). Kids are growing, Marina’ business doing ok. How’s life on your side? Would love to meet, lunch or so? Cheers, Jeff

On Jan 16, 2022, at 13:19, Jeff Tantsura <jefftant.ietf@gmail.com> wrote:

 Plane IP underlay works real well, I’m yet to see tangible proof of TE in DC (outside of niche HPC/IB cases). SR in DC - with overlay starting on the host SR-MPLSoUDP(RFC8663) is a perfect representation of a working technology that works in IP environment as well as allows end2end programming for MPLS WAN/DCI. Here’s an example of end2end architecture that works really well - https://datatracker.ietf.org/doc/draft-bookham-rtgwg-nfix-arch/

Geneve (there are some quirks as you get into implementing it) is another example of a well designed overlay encap.

Cheers, Jeff

...

...

On Jan 15, 2022, at 23:54, Saku Ytti <saku@ytti.fi> wrote:

On Sat, 15 Jan 2022 at 19:22, Colton Conor <colton.conor@gmail.com> 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

Marketing, not fundamentals. DC people are driving demand for VXLAN and SRv6, because they assume MPLS is something scary and complex. So vendors implement something scary and complex to appease DC people. I'm sure in some years to the future, DC people will re-invent MPLS to simplify their stack.

-- ++ytti