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.) -- Tim:>
Subject: draft-ietf-mpls-ldp-ipv6-16 Date: Thu, Feb 19, 2015 at 11:06:40AM -0500 Quoting Tim Durack (tdurack@gmail.com):
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. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'm having a BIG BANG THEORY!!
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 On 2/19/15, 16:06, "Tim Durack" <tdurack@gmail.com> wrote:
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.)
-- Tim:>
On 19/Feb/15 19:03, Phil Bedard wrote:
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.
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.
On 2/19/15, 2:27 PM, "Mark Tinka" <mark.tinka@seacom.mu> wrote:
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
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.
On 20/Feb/15 02:36, George, Wes wrote:
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.
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.
On (2015-02-19 11:06 -0500), Tim Durack wrote:
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.)
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? -- ++ytti
On Fri, Feb 20, 2015 at 6:39 AM, Saku Ytti <saku@ytti.fi> wrote:
On (2015-02-19 11:06 -0500), Tim Durack wrote:
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.)
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?
-- ++ytti
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. -- Tim:>
On (2015-02-20 09:00 -0500), Tim Durack wrote: 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. -- ++ytti
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
On Feb 20, 2015, at 1:19 PM, Saku Ytti <saku@ytti.fi> wrote:
On (2015-02-20 09:00 -0500), Tim Durack wrote:
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.
-- ++ytti
On 20/Feb/15 13:39, Saku Ytti wrote:
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?
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
On Feb 20, 2015, at 2:09 PM, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 20/Feb/15 13:39, Saku Ytti wrote:
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?
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.
participants (7)
-
George, Wes -
Jeff Tantsura -
Mark Tinka -
Måns Nilsson -
Phil Bedard -
Saku Ytti -
Tim Durack