Just want to sample the room and find out if anyone here - especially those running an LDP-based BGPv4-free core (or something close to it) - would be interested in LDPv6, in order to achieve the same for BGPv6?
A discussion I’ve been having with Cisco on the matter is that they do not “see any demand” for LDPv6, and thus, won’t develop it (on IOS XE). Meanwhile, it is actively developed, supported and maintained on IOS XR since 5.3.0, with new features being added to it as currently as 7.1.1.
Needless to say, a bunch of other vendors have been supporting it for a while now - Juniper, Nokia/ALU, Huawei, even HP.
IOS XR supporting LDPv6 notwithstanding, Cisco’s argument is that “the world” is heavily focused on deploying SRv6 (Segment Routing). While I know of one or two questionable deployments, I’m not entirely sure much of the world is clamouring to deploy SR, based on all the polls we’ve done at various NOG meetings and within the general list-based operator community
So I just wanted to hear from this operator community on whether you would be interested in having LDPv6 support to go alongside your LDPv4 deployments, especially if you run native dual-stack backbones. Or if your focus is totally on SRv6. Or if you don’t care either way :-). Thanks.
To be honest, I do not think we're going to buy any IOS XE gear in the
foreseeable future. But if we did, LDPv6 would be nice to have - to get
rid of IPv4 in the backbone network.
We have LDPv6 working beautifully between IOS XR (6.4.2) and Junos
(17.4). But we can't make the core BGPv6-free because downstream
ASR1000's and ASR920's don't have it.
So if you don't have IOS XE today, but have the others, then you're good
to go :-).
Nobody is going to demand LDPv6, because it's not about LDPv6... it's
about IPv6, and wanting IPv4 parity. But, guess that doesn't much a
business case write.
I would take either LDPv6 or SRv6 - but also need L3VPN (and now EVPN)
re-wired to use IPv6 NH.
At the moment, LDPv6 doesn't have what I call "service" support, i.e.,
l3vpn's, l2vpn's, MPLSv6-TE, mLDP, CsC, e.t.c. To be honest, I don't
mind those so much on my end because you can still run a BGP-free core
and still deliver those services.
Granted, if your goal is a single-stack MPLS-based IPv6 network, then
yes, it would be good for LDPv6 to support the "services".
But if it's just vanilla MPLSv6 switching you're after, then LDPv6 will
do just fine.
I have requested LDPv6 and SRv6 many times from Cisco to migrate the
routing control plane from IPv4 to IPv6
Well, according to them, SRv6 is winning customers over, and nobody
wants LDPv6. Then again, they have LDPv6 in IOS XR; figures.
I have lots of IPv6 address space. I don't have a lot of IPv4
address space. RFC1918 is not as big as it seems. Apparently this is
hard to grasp...
(This is primarily IOS-XE - can't afford the IOS-XR supercars)
LDPv6 must be a business case :-). Well, wonder how they sell so many
CGN's, then :-).
In its simplest form without TE paths, there isn't much to SRv6. You use a v6 address as an endpoint and a portion of the address to specify a specific VPN service. You completely eliminate the label distribution protocol.
Thanks,
Phil
I'm pretty sure that one or more of Mark, Gert or Tim are thinking
SR/MPLS IPv6 when they say SRv6?
No one in their right minds thinks SRv6 is a good idea, terrible snake
oil and waste of NRE. SR/MPLS IPv6 of course is terrific.
LDPv6 and SRv6 seem like an odd couple, LDPv6 SR/MPLS IPv6 seem far
more reasonable couple to choose from. I have my favorite.
I'm pretty sure that one or more of Mark, Gert or Tim are thinking
SR/MPLS IPv6 when they say SRv6?
Oh, not at all, Saku.
No one in their right minds thinks SRv6 is a good idea, terrible snake
oil and waste of NRE. SR/MPLS IPv6 of course is terrific.
LDPv6 and SRv6 seem like an odd couple, LDPv6 SR/MPLS IPv6 seem far
more reasonable couple to choose from. I have my favorite.
I've been tracking SR since it began making "waves" in Paris at a
previous MPLS/SDN/IPv6 Congress meeting a a 2013, or thereabouts. Plenty
of promise about being a decent alternative to LDPv6 (which had been on
my mind since 2008).
In the end, as you rightly point out, it's been much ado about nothing.
To this day, I am yet to hear from a single operator about all the
chanting I hear from vendors - and not just SRv6, but SR in general. 7
years and counting.
100% Eliminating label forwarding in core is not an asset, it is a
liability. Label forwarding is fast, cheap and simple[0]. You can do
it with on-chip memory in constant time. IP lookups are slow,
expensive and complex[0]. SRv6 marketing is false, bordering dishonest
marketing of an unclean abomination of a protocol. Every HW designer
has sighed in relief when I've said I don't care about it, because
it's also very HW unfriendly, like IPv6 generally. Unfortunately SRv6
is somewhat easy to market with the whole 'it's simple, just IP'
spiel.
[0] None of this is hard to measure, it is a known fact. And all of it
matters, you can measure lower jitter for MPLS than IP, you can better
carry DDoS traffic when using MPLS compared to IP and you can have
more ports in front-plate for the same money, by spending external
memory SERDES for WAN ports.
Then do IPv6-in-IPv6, and attach the inner IPv6 header to VRF,
pseudowire, what-have-you.
It is clear market needs tunnelling, and we should all understand that
colour of tunneling doesn't matter, what matters is how many bytes of
overhead does the tunnel add (the more bytes, the more bps leverage
attacker gets) and what is the cost of looking up the headers.
Evaluating 40B IPv6 and 4B MPLS tunneling headers based on objective
desirable qualities of tunneling, MPLS is blatantly better. But if
someone does not like MPLS, fair-game, they should have ability to do
IPV6 in IPv6 in IPv6 in IPv6, go crazy.
I'm not saying we can't improve over MPLS header, we can. But IPv6 is
just objectively inferior by key metrics of 'goodness' of tunneling.
Mine have sighed in disbelief that I don't share their vision of an
SR(v6) world :-).
What's funny is that the ASR920 does not support SRv6, which I think is
more due to hardware limitations than a lack of coding kiddies.
Conversely, you don't need new bits of hardware to support LDPv6.
Today, there is no box that supports LDPv4 that cannot support LDPv6, by
just extending the code. No further hardware needed.
Instead, I'm being asked to "upgrade" to the NCS540 so that I can get
LDPv6. You, sometimes, have to wonder in what world these folk live.
It's a Coronavirus era now - people want to hold on to all the $$ they
don't have, and only spend it where they will extract the most value.
Boeing and Airbus are struggling to reach customers that have pending
deliveries; now isn't the time for vendors to posture. We need value,
not product.
I don't like to conflate these two; SR is great, SRv6 is horrible
abomination. SR is what MPLS should have been day1, but it probably
was easier to market LDP than to say 'we need to change all IGP
protocols'.
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. And don't forget SRv6 is also heavily associated (marketing-wise) with 5G....
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.
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.
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".
Just want to sample the room and find out if anyone here - especially
those
running an LDP-based BGPv4-free core (or something close to it) - would be
interested in LDPv6, in order to achieve the same for BGPv6?
A discussion I've been having with Cisco on the matter is that they do not
"see any demand" for LDPv6, and thus, won't develop it (on IOS XE).
Meanwhile, it is actively developed, supported and maintained on IOS XR
since 5.3.0, with new features being added to it as currently as 7.1.1.
Needless to say, a bunch of other vendors have been supporting it for a
while now - Juniper, Nokia/ALU, Huawei, even HP.
IOS XR supporting LDPv6 notwithstanding, Cisco's argument is that "the
world" is heavily focused on deploying SRv6 (Segment Routing). While I
know
of one or two questionable deployments, I'm not entirely sure much of the
world is clamouring to deploy SR, based on all the polls we've done at
various
NOG meetings and within the general list-based operator community
So I just wanted to hear from this operator community on whether you
would be interested in having LDPv6 support to go alongside your LDPv4
deployments, especially if you run native dual-stack backbones. Or if your
focus is totally on SRv6. Or if you don't care either way :-). Thanks.
Hey Mark,
My stance is that should I go with anything "new" for label distribution the
MPLS SR/SPRING is getting to a point where it might be mature enough.
Also "BGP free core" means internet won't talk to your core -i.e. free to
use private addressing -so no need for v6 at all in the "underlay" (as
hipsters call it these days).
Alternatively using public "infrastructure subnet" (i.e. not advertised to
the Internet) for a "BGP free core", the aim is to make money of the core
-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?
And with regards to the XE/XR discrepancies, I mentioned my prophecy a
number of times, I think XE future in SP products portfolio is next to none.
I don’t know about you, but my BGP-free core is inaccessible from the world even if it lives in public-IPv4 land. That’s how pure MPLS forwarding works. You’d have be “inside” to reach it (IGP). Also, if you link every feature to a revenue stream, you’ll never deploy RPKI or DNSSEC :-). Which is fine - but customers are spending real money and need to keep real networks running with real costs for real years. If Cisco want to kick IOS XE to the side, let customers know so we can make informed decisions about where to purchase gear. The current state-of-the-art is that kit you buy today is probably good years after standard depreciation policies, probably longer. If Cisco’s model is to throw boxes away sooner than that like they did in the old days, that is not consistent with where the tech. has gotten to in the past 2 decades. Mark.