I notice draft-ietf-mpls-ldp-ipv6-16 was posted February 11, 2015.
What is the chance of getting working code this decade? I would quite like
to play with this new fangled IPv6 widget...
(Okay, I'd like to stop using IPv4 for infrastructure. LDP is the last
piece for me.)
I notice draft-ietf-mpls-ldp-ipv6-16 was posted February 11, 2015.
What is the chance of getting working code this decade? I would quite like
to play with this new fangled IPv6 widget...(Okay, I'd like to stop using IPv4 for infrastructure. LDP is the last
piece for me.)
One of the vendors has promised v6 ldp "this year" (as in 2015). Given
the interesting bugs that surfaced when we tried a couple years ago,
well, I'm at least breathing shallowly.
ASR9K IOS-XR 5.3.0 Release Notes:
IPv6 Support in MPLS LDP: Starting from release 5.3.0, support for native
MPLS LDP over IPv6 is enabled to continue providing existing services
seamlessly while enabling new ones. The attributes and capabilities of the
existing MPLS LDP have been extended to be IPv6 aware.
This is based off the -12 draft, that LDP over v6 draft has seen a lot of
contention for various reasons.
Details at:
http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/mp
ls/configuration/guide/b-mpls-cg53x-asr9k/b-mpls-cg53x-asr9k_chapter_010.ht
ml#concept_FA2F48EE4A2044458FE25897118AFBA4
If you have CCO access you can download the 5.3.0 XRv VMs and play around
with it.
Phil
Getting IPv6 support in LDP is one thing.
This is one document that we need to keep track to know what MPLS
applications currently running off of LDPv4 still need to be ported to
run over LDPv6:
http://tools.ietf.org/html/draft-george-mpls-ipv6-only-gap-04
Mark.
The document has come out the other side of the IETF sausage grinder now:
https://tools.ietf.org/html/rfc7439
Unfortunately, it's just a list of the gaps.
It is worth leaning on your vendors of choice to ensure that they have
people focused on addressing these issues, as not all of them have
volunteers to write the documents necessary to close those gaps yet.
Thanks
Wes George
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Looking at how long it has taken the community to react to the LDPv6
draft (been chasing everyone since 2007, personally), my priority to get
a working MPLSv6 domain has gone from 1 to a lot lower.
I'd like to see it get done, but I'm going to be focusing on getting
better native IPv6 in the code/hardware before I chase the vendors for a
working MPLSv6 solution. They just have no interest because there is no
incremental revenue - and given the community are focused on other
things, threatening not to buy kit due to lack of MPLSv6 support is not
a practical avenue, unfortunately.
Mark.
Is there 4PE implementation to drive IPv4 edges, shouldn't be hard to accept
IPv6 next-hop in BGP LU, but probably does not work out-of-the-box?
Isn't Segment Routing implementation day1 IPV4+IPV6 in XR?
I would gladly take OSPFv2/OSPFv3/ISIS+SR over LDP, but I'm seeing that is
not all that is needed.
I also need some flavor of L2VPN (eVPN) and L3VPN (VPNv4/VPNv6) working
over IPv6.
IPv6 control plane this decade may yet be optimistic.
I don't consider unique addressing of infrastructure a whim.
Hey Tim,
I also need some flavor of L2VPN (eVPN) and L3VPN (VPNv4/VPNv6) working
over IPv6.
L3VPN uses BGP exclusively for VPN label signalling, no need for LDP.
For L2VPN only Martini uses LDP, but if you have choice, why wouldn't you
choose Kompella, the scaling factor is superior, as you only have 2 signalling
connection, instead of n*(n-1)/2 signalling sessions. And you get to
capitalize on instantly available backuo path.
Of course I know that in CSCO land Kompella isn't available on every platform
where Martini is, so you indeed may need LDP for some time until old platforms
are phased out. 'Luckily' these older platforms have dubious IPv6 anyhow, so
you might opt them out from IPv6 deployment anyhow.
IPv6 control plane this decade may yet be optimistic.
For greenfield it's doable today (only Kompella pseudowires), but IPv6-only
would require 4PE, I don't know if that works/exists.
The last time I checked, MPLS support in SR for IPv6 is not a high
priority, compared to TE for IPv4 MPLS.
My thoughts that SR would automatically mean native label signaling in
IS-IS and OSPFv3 were otherwise ambitious.
Mark.
From market prospective v6 SR is definitely lower priority. Comcast and few more are looking into native rather than v6 with MPLS encap.
Wrt v4 - 2 weeks ago at EANTC in Berlin we have tested 3 implementations of ISIS SR v4 MPLS with L3VPN and 6VPE over SR tunnels. Worked very well, very few issues.
So there's production quality code and interoperability - given the timeframe we have done a really good job in IETF 
Regards,
Jeff
For L2VPN if you could make it work - go with EVPN day 1, it solves most of the issues present in both LDP and BGP VPLS implementations.
Be aware of differences in PBB vs plain EVPN and platform support.
EVPN, specifically multhoming/split horizon/some other stuff as well as presence of L3 (type 2/5) and complications of above brings lots of complexity into fast path processing and not every platform/NPU can do full spec.
Regards,
Jeff
Businesses bigger than me think there is a business driver for IPv6:
http://meetings.ripe.net/ripe-54/presentations/IPv6_management.pdf
http://www.internetsociety.org/deploy360/wp-content/uploads/2014/04/WorldIPv6Congress-IPv6_LH-v2.pdf
IPv6 management of equipment is relatively easy. Once you've started down
that path, you start looking at the protocol stuff, and wondering what to
do about that.
Maybe I should leave it alone until the business people figure it out for
me 
Tim:>