Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]
Hi Mans, On Fri, May 2, 2014 at 2:35 PM, Måns Nilsson <mansaxel@besserwisser.org>wrote:
This is a field where v4 next-hops are essential to make things work. <rant>In that context, allocating 100.64.0.0/10 to CGN was especially un-clever... </rant>
Would you expound a bit on what you mean here? I don't quite follow but I am very interested to understand the issue. Thanks! ~Chris -- @ChrisGrundemann http://chrisgrundemann.com
Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)] Date: Fri, May 02, 2014 at 03:58:42PM -0600 Quoting Chris Grundemann (cgrundemann@gmail.com):
Would you expound a bit on what you mean here? I don't quite follow but I am very interested to understand the issue.
The fact that you need v4 space to build a MPLS backbone is a very good reason to not waste a /10 on CGN crap. Ideally, we would have a solution where an entire MPLS infrastructure could be built without v4 space, demoting v4 to a legacy application inside a VRF, but the MPLS standards wg seems content with status quo. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I wish I was a sex-starved manicurist found dead in the Bronx!!
a good number of us use that kinky /10 behind home nats and encourage everyone to do so. it was a sick deal and should be treated as such, just more 1918. randy
On Sat, May 3, 2014 at 3:58 AM, Randy Bush <randy@psg.com> wrote:
a good number of us use that kinky /10 behind home nats and encourage everyone to do so. it was a sick deal and should be treated as such, just more 1918.
A good number of folks use other folks IP space in all kinds of strange and kinky ways too - it's ALL just more 1918, right??? Or maybe standards exist for a reason. Perhaps enhancing coordination, cooperation, and *interoperability* are good things... I'll let you decide, Randy; is it sick to solve problems through community consensus and standardization, or is it sick to be the one intentionally getting in the way of those real world solutions? Cheers, ~Chris
randy
-- @ChrisGrundemann http://chrisgrundemann.com
On 5/3/14, 10:36 AM, Chris Grundemann wrote:
On Sat, May 3, 2014 at 3:58 AM, Randy Bush <randy@psg.com> wrote:
a good number of us use that kinky /10 behind home nats and encourage everyone to do so. it was a sick deal and should be treated as such, just more 1918.
A good number of folks use other folks IP space in all kinds of strange and kinky ways too - it's ALL just more 1918, right??? Or maybe standards exist for a reason. Perhaps enhancing coordination, cooperation, and *interoperability* are good things... I'll let you decide, Randy; is it sick to solve problems through community consensus and standardization, or is it sick to be the one intentionally getting in the way of those real world solutions?
Any time you have two parties that have to interconnect who have overlapping usage of the same space you're going to have issues. The authors the 6598 were concerned about intersection with legacy CPE. 100.64.0.0/10 does not yet have that issue. The use cases being described here (randy causing pollution, numbering internal network resources (the intended purpose after all)) have no relationship to legacy CPE. characterizing it as shared was always a misnomer since by their nature collisions are not sharing. in a somewhat unrelated note this prefix is still leaking in some globally visible ways in some places. e.g. if you're as3303 you probably shouldn't be importing these prefixes from customers or exporting as part of your full table given that you also accept them from subsidiaries. that's likely to end in tears.
Cheers, ~Chris
randy
On Sat, May 3, 2014 at 3:26 AM, Måns Nilsson <mansaxel@besserwisser.org> wrote:
The fact that you need v4 space to build a MPLS backbone is a very good reason to not waste a /10 on CGN crap.
Ah, so you're in the camp that a /10 given to one organization for their private use would have been better than reserving that /10 for _everyone_ to use. We'll have to agree to disagree there.
Ideally, we would have a solution where an entire MPLS infrastructure could be built without v4 space, demoting v4 to a legacy application inside a VRF, but the MPLS standards wg seems content with status quo.
We can agree on that. Thanks, ~Chris
-- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I wish I was a sex-starved manicurist found dead in the Bronx!!
-- @ChrisGrundemann http://chrisgrundemann.com
Ah, so you're in the camp that a /10 given to one organization for their private use would have been better than reserving that /10 for _everyone_ to use. We'll have to agree to disagree there.
you forced an rfc allocation. that makes public space, and is and will be used as such. you wanted an 'owned' allocation that you and your friends control, you shoulda gone to the rirs. randy
Randy Bush <randy@psg.com> writes:
Ah, so you're in the camp that a /10 given to one organization for their private use would have been better than reserving that /10 for _everyone_ to use. We'll have to agree to disagree there.
you forced an rfc allocation. that makes public space, and is and will be used as such. you wanted an 'owned' allocation that you and your friends control, you shoulda gone to the rirs.
Usually I manage to keep the Strangelove hand in check and not feed the troll, but the matter was raised (at least in the ARIN region). https://www.arin.net/policy/proposals/2011_5.html I believe that the arguments that shared transition space were IETF's purview were compelling. I'm no fan of non-globally-unique space in general, but forcing the RFC route was the least-worst route for things to move forward. Randy, I trust that you're also vigorously advocating people's use of UK-MOD-19850128 (aka net 25) as "just more 1918 space" inside their organizations too? After all, it's what I encourage *my* competitors to do. -r
On Saturday, May 03, 2014 11:26:27 AM Måns Nilsson wrote:
Ideally, we would have a solution where an entire MPLS infrastructure could be built without v4 space, demoting v4 to a legacy application inside a VRF, but the MPLS standards wg seems content with status quo.
There is work ongoing in the MPLS IETF WG on identifying the gaps that various MPLS applications have so they can be prepared for IPv6 MPLS control and data planes. Long overdue, if you ask me, but at least it's starting to get some attention. Mark.
Ideally, we would have a solution where an entire MPLS infrastructure could be built without v4 space, demoting v4 to a legacy application inside a VRF, but the MPLS standards wg seems content with status quo.
There is work ongoing in the MPLS IETF WG on identifying the gaps that various MPLS applications have so they can be prepared for IPv6 MPLS control and data planes.
Long overdue, if you ask me, but at least it's starting to get some attention.
Mark.
You mean the SR right? adam
On Monday, May 05, 2014 09:27:37 AM Vitkovský Adam wrote:
You mean the SR right?
No, I mean: draft-george-mpls-ipv6-only-gap-05 The draft looks at issues that need to be fixed for MPLS to run in a single-stack IPv6 network. Of course, there is other work that is looking at fixing LDPv6 as well, as you know. At the recent MPLS SDN Congress in Paris, I asked some folk about leveraging SR to push native IPv6 support into MPLS, but they didn't seem like that was a key application yet. So while SR is promising, I think it's not a solution for this particular use-case yet. Mark.
Mark,
about leveraging SR to push native IPv6 support into MPLS,
Segment routing (SR) could/would certainly work with single-stack v6 and enable MPLS forwarding. Cheers, Rajiv
On May 5, 2014, at 3:36 AM, "Mark Tinka" <mark.tinka@seacom.mu> wrote:
On Monday, May 05, 2014 09:27:37 AM Vitkovský Adam wrote:
You mean the SR right?
No, I mean:
draft-george-mpls-ipv6-only-gap-05
The draft looks at issues that need to be fixed for MPLS to run in a single-stack IPv6 network.
Of course, there is other work that is looking at fixing LDPv6 as well, as you know.
At the recent MPLS SDN Congress in Paris, I asked some folk about leveraging SR to push native IPv6 support into MPLS, but they didn't seem like that was a key application yet. So while SR is promising, I think it's not a solution for this particular use-case yet.
Mark.
On Tuesday, May 06, 2014 11:27:09 AM Rajiv Asati (rajiva) wrote:
Segment routing (SR) could/would certainly work with single-stack v6 and enable MPLS forwarding.
Certainly, but based on the Paris meeting, it was not high up on the agenda. So we will, likely, have to rely on other solutions and wait for SR to catch up later. At the moment, it seems SR is being pushed hard for PCEP as well as SDN. Mark.
From: Mark Tinka [mailto:mark.tinka@seacom.mu]
On Tuesday, May 06, 2014 11:27:09 AM Rajiv Asati (rajiva) wrote:
Segment routing (SR) could/would certainly work with single-stack v6 and enable MPLS forwarding.
Certainly, but based on the Paris meeting, it was not high up on the agenda.
So we will, likely, have to rely on other solutions and wait for SR to catch up later.
At the moment, it seems SR is being pushed hard for PCEP as well as SDN.
Mark.
I think the most revolutionary SR use case is the: 3.2. Protecting a node segment upon the failure of its advertising node. Of the now expired: draft-filsfils-rtgwg-segment-routing-use-cases-02. It's the first, complete and elegant FRR solution for the hierarchical MPLS implementations. adam
inside a VRF, but the MPLS standards wg seems content with status quo.
http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6 The WG is pretty close to wrap this up (back to the 3rd WGLC very soon). But frankly admitting, dual-stacking facilitated more issues than I expected early on. Cheers, Rajiv
On May 3, 2014, at 5:29 AM, "Måns Nilsson" <mansaxel@besserwisser.org> wrote:
Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)] Date: Fri, May 02, 2014 at 03:58:42PM -0600 Quoting Chris Grundemann (cgrundemann@gmail.com):
Would you expound a bit on what you mean here? I don't quite follow but I am very interested to understand the issue.
The fact that you need v4 space to build a MPLS backbone is a very good reason to not waste a /10 on CGN crap.
Ideally, we would have a solution where an entire MPLS infrastructure could be built without v4 space, demoting v4 to a legacy application inside a VRF, but the MPLS standards wg seems content with status quo.
-- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I wish I was a sex-starved manicurist found dead in the Bronx!!
participants (8)
-
Chris Grundemann -
joel jaeggli -
Mark Tinka -
Måns Nilsson -
Rajiv Asati (rajiva) -
Randy Bush -
Rob Seastrom -
Vitkovský Adam