LDPv6 Census Check

Well, given their (Cisco's) braindead policy regarding non-implementation of LDPv6 on XE, no wonder people are looking for alternatives, and SRv6 is one of them.

Which doesn't track because there are a number of IOS XE boxes that do
not support SRv6, and probably never will. Meanwhile, no issue with
those boxes supporting LDPv6, as they already support LDPv4.

And don't forget SRv6 is also heavily associated (marketing-wise) with 5G....

Well, we all know the farce that is 5G.

Also, not all of us run mobile networks, and even for those that do,
there are probably a few that don't buy into the snake oil, especially
those that offer native IPv6 to their mobile customers :-).

Back to our friends and their policy: It happens that in certain regions of the world, if you want to be an ISP other than the "establishment" (== incumbent + "first alternatives" that started 20-25 years ago), you MUST have LNS (if you want to stay in business). If like many, you are kind of stuck with Cisco because it's Cisco, the only decent solution to have LNS is ASR1K (running XE). Also add ASR920 which has a number of uses. Also, in order to stay in business, you may want to offer L3VPN services, which brings you to doing MPLS. You say MPLS, you say LDP, and there you go, your backbone remains v4-based for the next eternity.

Which I would understand if Cisco's strategy, as a company, was anti-LDP.

But when you have the IOS XR team actively supporting LDP and adding new
features with each major release, the split brain is obvious. You can't
come to me under a "unified" organizational banner, and then tell me you
are a-thousand companies internally. If you choose to fork code into
IOS, IOS XE, IOS XR, NX OS, or whatever new flavour of the decade, don't
make that my problem. Customers don't buy code; they buy boxes that are
built for the task. The code that comes with it is the code that comes
with it.

Moreover, IOS XE also has its own split BU's. So getting IOS XE fixed
for the ASR920 doesn't necessarily mean you get it fixed for the
ASR1000. I mean, how much more complicated does a business have to be?

There also seems to be a lack of global vision. Tyry to ask your favourite vendor what do you need in order to be able to offer IPv4-L3VPN, IPv6-L3VPN and L2VPN (mainly point-to-point - NO MAC learning) over a backbone that does NOT use any single IPv4 address (backbone-side). Because you can do it on a backbone that does not use any single IPv*6* address, but you may want to go forwards, not backwards. Add a LNS in the mix (the v4 addresses for the LNS go in VRFs - that's not backbone). Add a money, rack space and power needed constraints in the mix. This exercise looks challenging with other vendors too, but with Cisco it's just impossible.

That's because it's not about l3vpn6 or l2vpn6; it's about IPv6. And you
can't business-case IPv6.

Some vendors fail to understand that IPv6 is not the money-maker. IPv6
is what attracts the customer to the network so that the money can flow.
It's a means to an end, not the end in itself.

Of course, Cisco says there is no demand for one simple reason : the people talking with Cisco account managers (or whatever they are called) are only rarely those that care about technical stuff. They may want some features on the CPEs (like "ui uant SDWAN"), but for anything else (including backbone equipment) they only want lower prices. You end up with everybody having to deal with a specific platform in real life to dream about a specific feature, yet the vendor to consider that "nobody wants it".

One of the reasons I've never been keen on working for a vendor is
tunnel vision becomes easy. As an operator, you have a much wider view
of what's happening in the real world. When a vendor decides to home-in
on EoMPLS and VPLS being better signaled by LDP vs. BGP, you end up with
situations where they track user-demand through the number of TAC cases
the feature caused. The fewer the TAC cases, the lower the demand. Very
scientific.

Nobody is going to demand LDPv6 because the over-arching problem is a
lack of IPv6 deployment at global scale. If folk don't deploy IPv6, they
will not think about LDPv6, RSVPv6, e.t.c. But to make it worse, if the
vendors keep encouraging the "big-spending" mobile operators to maintain
IPv4 by selling CGN licenses, it's kind of back-to-front, isn't it? No
operator unwilling to deploy IPv6 but favours CGN is ever going to ask a
vendor about LDPv6, especially if the vendor is in charge of building
and operating that backbone as a "professional, managed service".

Ultimately, we are not asking for an ASIC re-spin. We are not asking for
a doubling of forwarding capacity. We are not asking for a greener
chassis. We are not asking for 100Gbps ports. All of which are
physically impossible. We are asking for LDP to extended to support
IPv6. Really, how hard is that?

Mark.

Nearly impossible, apparently.

It would require a change of mindset.

Nick

I'll leave that to the Coronavirus - it will open eyes.

Mark.

I get this for VLAN’s, being only 4,096 per broadcast domain and all. But are we struggling with scaling label space? Just my 1+1, since I may be over-simplifying the issue. I found multi-level IS-IS to be useless in an MPLS network because you still need to leak routes between L2 and L1 in order to form MPLS FEC’s. So you simplify the network by having a single L2 (or just Area 0 in OSPF), because today’s control planes can handle it. And yes, some are brave enough to run RFC 3107 if it becomes a problem, but if you can afford to string a network together across all continents, I doubt an x86-based control plane with 64GB of RAM is topping the list of your problems. Mark.

Nope that was not the main reason.

Main reason was the belief that labels MUST be locally significant - and not domain wide unique. Just look at Juniper's SRm6 or now SRH ... they keep this notion of locally significant SIDs. It is deep in their DNA ... still.

Seems weird, because neither LDP or SR implies globally significant
labels, implementation choice. What SR does imply is a continuous
block of labels of equal size in domain.

Now to your runt that MPLS is great because of exact match perhaps you missed it but number of solutions on the table (including RbR[**] I recently proposed) use exact match 4B locator based lookup in the v6 packets to get from segment end to segment end.

Which is making a simple thing a complex thing.

On the other hand your comments about greatness of MPLS ... simplified data plane and depending on the hardware difference in jitter (in sub ms ranges - if that even matters) comes up with a lot of control plane complexity when you want to build a network across all continents, yet keep it scoped from IGP to areas or levels. No summarization in MPLS in FECs is something we should not sweep under the carpet.

MPLS complexity is trivial in control-plane and forwarding-plane
compared to IPV6 or SRv6 or RbR[**]. I'm not saying we can't do better
than MPLS, but the proposal here is blatantly worse.

Thanks, Drikus.

If you can get your AM to get in touch with the ASR920 and ASR1000 BU's
to ask for LDPv6, that will help a great deal. Cisco are saying "no one"
is asking for LDPv6, forgetting that it's more about IPv6, than other
lower/higher-level services it can support, LDPv6 included.

As with you, they are trying to shove SRv6 down our throats, which can
only come on an NCS540 for the moment, which is odd since that runs IOS
XR, which supports LDPv6. So basically, swap out tons of boxes to get a
feature that can easily be coded for in existing hardware... makes you
wonder about the thought-process;

It's been a crazy two weeks with our Cisco AM's and the platform TME's
on heated calls about this that it's almost old testament biblical :-).
It's at the stage where it's going up the chain to the BU's who will
make the final call. So if they can get some noise from you as well, it
certainly won't hurt.

You don't need new hardware features on the ASR920 or ASR1000 to support
LDPv6. You might do for SRv6. Either way, both platforms would need both
features developed in code, and I think it's safe to assume which one
will be practically easier to build and roll-out to the entire MPLS
customer base, today.

Mark.

From: Mark Tinka <mark.tinka@seacom.mu>
Sent: Thursday, June 11, 2020 10:21 AM

-what additional revenue stream am I getting by enabling v6 in the
underlay/management plane that would offset the pain of dealing with the
increased bug surface?

Also, if you link every feature to a revenue stream, you'll never deploy
RPKI or DNSSEC :-).

Well RPKI or DNSSEC is at least adding a value, even something you can brag about to your customers (we are part of the solution not part of the problem etc...).

But running MPLS over IPv6 in addition to already running it over IPv4, gaining new functionality or features in the process that could be ultimately monetized in providing better service to customers? -maybe even exposing the network to a new set of bugs? -I don't know, that doesn’t sound like a good use of company resources especially in these uncertain times . Maybe I'm being overly harsh here maybe if you could please explain the drivers or expected net value out of this exercise please?

adam

Well RPKI or DNSSEC is at least adding a value, even something you can brag about to your customers (we are part of the solution not part of the problem etc...).

Bragging doesn't bring in income, it's just PR :-).

But running MPLS over IPv6 in addition to already running it over IPv4, gaining new functionality or features in the process that could be ultimately monetized in providing better service to customers? -maybe even exposing the network to a new set of bugs? -I don't know, that doesn’t sound like a good use of company resources especially in these uncertain times . Maybe I'm being overly harsh here maybe if you could please explain the drivers or expected net value out of this exercise please?

Oh dear, you sound like our Finance department now; "drivers" and "net
value" :-).

If I take your line of reasoning, deploying SRv6 likely requires new
hardware, which means $$. How much money will I charge customers for my
shiny new SRv6?

LDPv6 builds on LDPv4. Just like IPv6 builds on IPv4. At best, you can
remove BGPv6 from your core, which lowers your administration costs in
that part of the network even further, costing you less in human time
running it, resources you can otherwise re-deploy to other time- and
money-saving activities. At worst, you get IPv4/IPv6 feature parity, and
who doesn't like that :-).

And how much money did LDPv6 cost you to deploy? $0.

Mark.

Not "in addition to" but "to throw out the IPv4 part" :slight_smile:

That's another view-point, yes.

There are plenty of networks that can't afford to keep buying IPv4 on
the open market. They want to go single-stack IPv6.

Today, you would need to build a 6PE network if you want MPLS support in
your IPv6-only network, which still requires IPv4. Private IPv4 address
space works, but some people like it, some don't, and more importantly,
you still carry around IPv4.

You could try the SRv6 gravy, but now you probably need new kit. What's
the SRv6 business-case? Well, one would say you save millions of $$ not
buying IPv4, but now you've spent money supporting SRv6.

LDPv6 can be supported by any platform that supports MPLS today. No
money out the door. Cisco would need to develop code for both LDPv6 and
SRv6 anyway, so no harm done on that side.

As we used to say in Vladivostok, "It's simple physics :-)".

(If I had LDPv6 today, I wouldn't actually change the existing network
today. But for the next round of rebuilding things, it would be something
to consider...)

Give your favorite Cisco AM a shout-out. I promise, they are probably
too young to remember your 6500/7600 tickets :-).

Mark.

Unsure of others, but we didn't implement RPKI for shit and giggles,
we implemented it, because customers wanted us to do RPKI.

I'll be honest, none of our customers ever asked us to deploy RPKI and
ROV. Will they benefit from it, sure? Is it about to become part of an
RFP requirements document? Probably not.

Then again, the typical NTT customer probably has an engineering
department that understands and demands RPKI, because they are a
sizeable operator themselves. We only have a handful of customers that
technically appreciate that we've deployed RPKI. For the rest, it
doesn't register.

Not sure if beating up on Job for months qualifies as "a customer
wanting RPKI from NTT" :-).

Mark.

From: Mark Tinka <mark.tinka@seacom.mu>
Sent: Thursday, June 11, 2020 1:56 PM

> Well RPKI or DNSSEC is at least adding a value, even something you can
brag about to your customers (we are part of the solution not part of the
problem etc...).

Bragging doesn't bring in income, it's just PR :-).

Good PR might :wink:

>
> But running MPLS over IPv6 in addition to already running it over IPv4,
gaining new functionality or features in the process that could be ultimately
monetized in providing better service to customers? -maybe even exposing
the network to a new set of bugs? -I don't know, that doesn’t sound like a
good use of company resources especially in these uncertain times . Maybe
I'm being overly harsh here maybe if you could please explain the drivers or
expected net value out of this exercise please?

Oh dear, you sound like our Finance department now; "drivers" and "net
value" :-).

I thought I sound like a network architect :frowning:

If I take your line of reasoning, deploying SRv6 likely requires new hardware,
which means $$. How much money will I charge customers for my shiny new
SRv6?

No, my line of reasoning is if you have MPLS LSPs signalled over v4 I see no point having them signalled also over v6 in parallel.
Or if your full-mesh RSVP-TE is killing your RSVP-TE or you're in need of TE, then might want to look at SR MPLS.

LDPv6 builds on LDPv4. Just like IPv6 builds on IPv4. At best, you can remove
BGPv6 from your core,

I'm using VPNv6 & VPNv4 so not sure I follow how LDPv6 allows for removal of BGPv6 (is it BGPv6 over v4 NHs/transport?) but then again if it works over v4...

which lowers your administration costs in that part of
the network even further, costing you less in human time running it,
resources you can otherwise re-deploy to other time- and money-saving
activities. At worst, you get IPv4/IPv6 feature parity, and who doesn't like
that :-).

I knew there's a bit of OCD hidden in this at some level :slight_smile:

And how much money did LDPv6 cost you to deploy? $0.

Apart from X months worth of functionality, performance, scalability and interworking testing -network wide code upgrades to address the bugs found during the testing process and then finally rollout across the core and possibly even migration from LDPv4 to LDPv6, involving dozens of people from Arch, Design, OPS, Project management, etc... with potential for things to break while making changes in live network.

adam

I'm sure we can blame Job for this, why not. But probably because of
his lobbying some customers are _requiring_, i.e. flat out told they
will stop accepting transit offers from providers who don't do RPKI.

From: Saku Ytti <saku@ytti.fi>
Sent: Thursday, June 11, 2020 3:29 PM

> Not sure if beating up on Job for months qualifies as "a customer
> wanting RPKI from NTT" :-).

I'm sure we can blame Job for this, why not. But probably because of his
lobbying some customers are _requiring_, i.e. flat out told they will stop
accepting transit offers from providers who don't do RPKI.

Case in point.

On the other hand not sure if any of the customers would care whether LSPs are signalled over v4 as opposed to v6.

adam

As my Chad friend would say, "I like the sound of this".

Mark.

They care if your core router CPU doesn't struggle from dealing with
churning BGP routes at scale, taking the network down.

Not every bit of good network operation can be attributed to direct
revenue. BCP-38 is a great example, and that is still poorly deployed
despite being supported.

Mark.

Good PR might :wink:

I'm old school - build something customers want to use, and the money
follows.

Care to guess how much PR Tik Tok do :-)? But I digress.

No, my line of reasoning is if you have MPLS LSPs signalled over v4 I see no point having them signalled also over v6 in parallel.

It's not about signaling IPv4 LSP's over IPv6.

LDPv4 creates IPv4 FEC's.

LDPv6 creates IPv6 FEC's.

The idea is to create IPv6 FEC's so that IPv6 traffic can be
label-switched in the network natively, allowing you to remove BGPv6 in
a native dual-stack core.

Or if your full-mesh RSVP-TE is killing your RSVP-TE or you're in need of TE, then might want to look at SR MPLS.

No RSVP-TE here, thank the Lord :-).

I'm using VPNv6 & VPNv4 so not sure I follow how LDPv6 allows for removal of BGPv6 (is it BGPv6 over v4 NHs/transport?) but then again if it works over v4...

Nothing like the real thing:

In IPv4-land, you get this:

24005 49017 105.16.Y.Z/32 Te0/0/0/2 105.16.A.B 8614773
49017 105.16.Y.Z/32 Te0/1/0/0 105.16.C.D 8121753
49017 105.16.Y.Z/32 Te0/7/0/5 105.16.E.F 9964543

In IPv6-land, you get this:

2c0f:feb0:X:Y::Z/128 25071 25458 BE1 Link-local
25458
BE2 Link-local

In Junos land, it looks like this:

7967 *[LDP/9] 1w5d 01:21:05, metric 1
> to fe80::de38:e1ff:fe15:dc02 via ae2.0, Swap
145674

If I run an IPv6 traceroute toward a host that sits behind a router
doing LDPv6, this is what happens:

run traceroute 2c0f:feb0:2f:ff00:WWWW:XXXX:YYYY:ZZZZ
traceroute6 to 2c0f:feb0:2f:ff00:WWWW:XXXX:YYYY:ZZZZ
(2c0f:feb0:2f:ff00:WWWW:XXXX:YYYY:ZZZZ) from 2c0f:feb0:1:2::112, 64 hops
max, 12 byte packets
1 ae-5-0.er6-01-fra.de.seacomnet.com (2c0f:feb0:1:2::111) 165.567 ms
166.158 ms 166.924 ms
MPLS Label=145786 CoS=0 TTL=1 S=1
2 xe-0-0-0-0.cr6-02-mrs.fr.seacomnet.com (2c0f:feb0:1:2::f9) 165.682
ms 2c0f:feb0:1:2::279 (2c0f:feb0:1:2::279) 165.817 ms 168.123 ms
MPLS Label=25494 CoS=0 TTL=1 S=1
<snip>

As you can see, just as with IPv4, IPv6 packets are now being
MPLS-switched in the core, allowing you to remove BGPv6 in the core and
simplify operations in that area of the network.

So this is native MPLSv6. It's not 6PE or 6VPE.

Your IPv4 domain could fall over and your MPLSv6 network will still be
alive, because it's neither 6PE nor 6VPE. And vice versa - your IPv6
network could die, and your MPLSv4 will be unaffected.

I knew there's a bit of OCD hidden in this at some level :slight_smile:

Safe to say the Internet is one big OCD project :-).

My OCD is sleeping at 3AM, in peace, lockdown or not, hehe.

Apart from X months worth of functionality, performance, scalability and interworking testing -network wide code upgrades to address the bugs found during the testing process and then finally rollout across the core and possibly even migration from LDPv4 to LDPv6, involving dozens of people from Arch, Design, OPS, Project management, etc... with potential for things to break while making changes in live network.

Which you wouldn't have to do with SRv6, because you trust the vendors?

And no, LDPv6 does not call for one to migrate from LDPv4. They can live
together, side-by-side, just as native dual-stack IPv4/IPv6 does.

We are running LDPv4 and LDPv6 side-by-side, with no problems, between
IOS XR and Junos, as you can see above. This is a live network, carrying
revenue-generating, production traffic. It's not a fantasy.

Mark.

It continues to be very much true. IP lookups require external memory,
which takes SERDES, which could be used for revenue otherwise. IP
lookups are slow, expensive and complex, fundamentally, no amount of
advancement will change this fundamental nature.
Sure we can come up with all kind of implementations which bridge the
gap, but the gap is there.

If we take say JNPR MX, your lookup speed isn't limited by the
instruction count on the PPE, the PPE spends most of its time
sleeping, when the platform is fully PPS congested, the PPE is waiting
for the memory to return!

Just to clarify the only routers who potentially need to inspect or do anything with those headers are endpoints who require information in the extension header or hops in an explicit path. In the simple example I gave, there are no extension headers at all.

I'm pretty agnostic to IPv6 SR-MPLS and SRv6, but just want to clarify that.

I'm not going to claim inserting/swapping v6 extension headers is what all routers made in the last 20 years are especially good at. ( But it's not impossible to do it in some shipping devices today at wire rate with deterministic latency.

As for normal v6 forwarding, the way most higher speed routers made recently work there is little difference in latency since the encapsulation for the packet is done in a common function at the end of the pipeline and the lookups are often in the same memory space. NPUs are also being built today with enough on-package memory to hold larger routing tables. Whether a packet has to be buffered on-chip vs. off-chip has a much larger impact on latency/PDV than a forwarding lookup.

Thanks,
Phil

On-package is not important, on-chip or off-chip is what matters, i.e.
do you eat SERDES to connect memory or not.

Of course you could always implement a software feature that says
these 32b/32 or 128b/128 addresses are blessed and need to live on
tiny on-chip memory and from this CIDR we guarantee all are host
routes. To achieve similar-to-MPLS performance, with few more bytes
per number.

The demand is, we need tunneling, then the question is what are the
metrics of a good tunneling solution. By answering this honestly, MPLS
is better. We could do better surely, but IP is not that.