|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
X-Original-To: nanog@nanog.org From: Jeff Tantsura <jeff.tantsura@ericsson.com> To: Mark Tinka <mark.tinka@seacom.mu> Date: Fri, 20 Feb 2015 22:29:57 +0000 In-Reply-To: <54E7AFFD.3090502@seacom.mu> Cc: "nanog@nanog.org" <nanog@nanog.org> Errors-To: nanog-bounces@nanog.org 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, ver= y few issues. So there's production quality code and interoperability - given the timefra= me 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: >=20 >=20 >=20 >> On 20/Feb/15 13:39, Saku Ytti wrote: >>=20 >> Is there 4PE implementation to drive IPv4 edges, shouldn't be hard to ac= cept >> 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? >=20 > The last time I checked, MPLS support in SR for IPv6 is not a high > priority, compared to TE for IPv4 MPLS. >=20 > My thoughts that SR would automatically mean native label signaling in > IS-IS and OSPFv3 were otherwise ambitious. >=20 > Mark.
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |