Re: draft-ietf-mpls-ldp-ipv6-16

2015-02-22 Thread Nick Hilliard
On 21/02/2015 14:28, Rogers, Josh wrote:
 RFC7349 is a nice summary of everything we¹re still missing wrt MPLS and
 is relatively recent so should be close to up to date.  In addition to the
 MPLS shortcomings, it also touches on recent IGP updates:

rfc7439, not 7349:

https://tools.ietf.org/html/rfc7439

Nick

 
 3.2.3.1.  Interior Gateway Protocol (IGP)

   RFC 3630 [RFC3630] specifies a method of adding traffic engineering
   capabilities to OSPF Version 2.  New TLVs and sub-TLVs were added in
   RFC 5329 [RFC5329] to extend TE capabilities to IPv6 networks in OSPF
   Version 3.

   RFC 5305 [RFC5305] specifies a method of adding traffic engineering
   capabilities to IS-IS.  New TLVs and sub-TLVs were added in RFC 6119
   [RFC6119] to extend TE capabilities to IPv6 networks.

   Gap: None.
 
 When you talk to your vendor, ask what code will support these RFC¹s.
 
 
 -Josh
 
 
 
 On 2/21/15, 6:00 AM, nanog-requ...@nanog.org nanog-requ...@nanog.org
 wrote:

 --

 Message: 1
 Date: Fri, 20 Feb 2015 09:00:07 -0500
 From: Tim Durack tdur...@gmail.com
 To: Saku Ytti s...@ytti.fi
 Cc: nanog@nanog.org nanog@nanog.org, Juniper-Nsp
  juniper-...@puck.nether.net, cisco-...@puck.nether.net
  cisco-...@puck.nether.net
 Subject: Re: draft-ietf-mpls-ldp-ipv6-16
 Message-ID:
  cae_ug16fgyqxstuyp9o+utdhdnpgbgfe6h5ebu4tdhb73vm...@mail.gmail.com
 Content-Type: text/plain; charset=UTF-8

 On Fri, Feb 20, 2015 at 6:39 AM, Saku Ytti s...@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:


 
 
 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.
 



Re: draft-ietf-mpls-ldp-ipv6-16

2015-02-21 Thread Rogers, Josh

RFC7349 is a nice summary of everything we¹re still missing wrt MPLS and
is relatively recent so should be close to up to date.  In addition to the
MPLS shortcomings, it also touches on recent IGP updates:


3.2.3.1.  Interior Gateway Protocol (IGP)

   RFC 3630 [RFC3630] specifies a method of adding traffic engineering
   capabilities to OSPF Version 2.  New TLVs and sub-TLVs were added in
   RFC 5329 [RFC5329] to extend TE capabilities to IPv6 networks in OSPF
   Version 3.

   RFC 5305 [RFC5305] specifies a method of adding traffic engineering
   capabilities to IS-IS.  New TLVs and sub-TLVs were added in RFC 6119
   [RFC6119] to extend TE capabilities to IPv6 networks.

   Gap: None.

When you talk to your vendor, ask what code will support these RFC¹s.


-Josh



On 2/21/15, 6:00 AM, nanog-requ...@nanog.org nanog-requ...@nanog.org
wrote:

--

Message: 1
Date: Fri, 20 Feb 2015 09:00:07 -0500
From: Tim Durack tdur...@gmail.com
To: Saku Ytti s...@ytti.fi
Cc: nanog@nanog.org nanog@nanog.org, Juniper-Nsp
  juniper-...@puck.nether.net, cisco-...@puck.nether.net
  cisco-...@puck.nether.net
Subject: Re: draft-ietf-mpls-ldp-ipv6-16
Message-ID:
  cae_ug16fgyqxstuyp9o+utdhdnpgbgfe6h5ebu4tdhb73vm...@mail.gmail.com
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 20, 2015 at 6:39 AM, Saku Ytti s...@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:




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.


Re: draft-ietf-mpls-ldp-ipv6-16

2015-02-20 Thread Saku Ytti
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


Re: draft-ietf-mpls-ldp-ipv6-16

2015-02-20 Thread Mark Tinka


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.


Re: draft-ietf-mpls-ldp-ipv6-16

2015-02-20 Thread Tim Durack
On Fri, Feb 20, 2015 at 6:39 AM, Saku Ytti s...@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:


Re: draft-ietf-mpls-ldp-ipv6-16

2015-02-20 Thread Mark Tinka


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.


Re: draft-ietf-mpls-ldp-ipv6-16

2015-02-20 Thread Jeff Tantsura
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 s...@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


Re: draft-ietf-mpls-ldp-ipv6-16

2015-02-20 Thread Jeff Tantsura
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.ti...@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.


Re: draft-ietf-mpls-ldp-ipv6-16

2015-02-20 Thread Saku Ytti
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


Re: [j-nsp] draft-ietf-mpls-ldp-ipv6-16

2015-02-20 Thread Tim Durack
On Fri, Feb 20, 2015 at 6:02 PM, Adam Vitkovsky adam.vitkov...@gamma.co.uk
wrote:

  Alright so would you mind sharing the business drivers that would make
 you migrate your current production infrastructure to this new unproven
 possibly buggy LDPv6 and 4PE/4VPE setup please?



 adam


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:


Re: [j-nsp] draft-ietf-mpls-ldp-ipv6-16

2015-02-20 Thread Tim Durack
On Fri, Feb 20, 2015 at 11:33 AM, Adam Vitkovsky adam.vitkov...@gamma.co.uk
 wrote:

  Of Tim Durack
  Sent: 20 February 2015 14:00
  IPv6 control plane this decade may yet be optimistic.
 

 And most importantly it's not actually needed it's just a whim of network
 operators.

 adam


 --
 This email has been scanned for email related threats and delivered safely
 by Mimecast.
 For more information please visit http://www.mimecast.com
 --


I don't consider unique addressing of infrastructure a whim.

-- 
Tim:


Re: draft-ietf-mpls-ldp-ipv6-16

2015-02-19 Thread Mark Tinka


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.


draft-ietf-mpls-ldp-ipv6-16

2015-02-19 Thread Tim Durack
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:


Re: draft-ietf-mpls-ldp-ipv6-16

2015-02-19 Thread Måns Nilsson
Subject: draft-ietf-mpls-ldp-ipv6-16 Date: Thu, Feb 19, 2015 at 11:06:40AM 
-0500 Quoting Tim Durack (tdur...@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!!


signature.asc
Description: Digital signature


Re: draft-ietf-mpls-ldp-ipv6-16

2015-02-19 Thread Phil Bedard
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 tdur...@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:



Re: draft-ietf-mpls-ldp-ipv6-16

2015-02-19 Thread George, Wes

On 2/19/15, 2:27 PM, Mark Tinka mark.ti...@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.