Hi Mans,
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.
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
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
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
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.
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
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
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.
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
inside a VRF, but the MPLS standards wg seems content with status quo.
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
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
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]
> 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