On Sun, 14 Feb 2010, Robin Whittle wrote:
I believe that once you understood the proposals in detail, the question
of what is being split or separated would matter to you.
Ok, I'm not sure I'm completely happy to have my understanding
denigrated like that, when it could perhaps just be that I understand
but don't consider certain things important at this point. :) But
hey...
You can do this and so ignore what I wrote - but you haven't argued
why anyone else should do the same or why I or anyone else should
respect your choices.
I didn't ignore what you said - CEE doesnt do tunneling. I'm trying
to connect my terminology with yours and check whether they match.
No - you can use "Core-Edge Separation" and "Core-Edge Elimination". I
am trying to be concise.
I don't really understand those terms tbh. I have had a glance
through the RRG wiki (the "terminology" page particularly), and your
http://www.firstpr.com.au/ip/ page, but I don't find an explanation.
The general architecture I'm familiar with that doesn't do tunneling
instead uses address rewriting of some form. So I tend to call it
"rewriting".
I'll try get accustomed to your terminology, but perhaps till then
you can try tolerate mine. :)
because there's no way the world will alter all its host stacks or
(for most CEE architectures) rewrite its applications *completely*
That is a significant concern alright. The only reason such a
suggestion isn't complete crack is cause:
- The world basically already did this for IPv6, so we know what it
involves.
- The apps that have updated should, by and large, now be using
address family abstracting interafaces, making future changes
slightly less painful.
CEE architectures can only provide substantial benefits to adoptors
and only provide real scaling benefits, when all, or almost all,
networks adopt the new architecture. This means moving everyone to
IPv6 and altering all host stacks to implement the particular CEE
architecture's alteration of IPv6.
I'd disagree with this. If you read the blog entry I'm outlining a
scenario where the immediate problem to be solved is pressure on NAT
(not multi-homing), leading to hacks being deployed which benefit both
customer and ISP together. These hacks then can be later, slowly,
extended to things like multi-homing.
I don't see how the above paragraph relates to you disagreeing with the
paragraph of mine before it.
What you are proposing is neither a CEE nor a CES architecture. You are
proposing to extend the port range of IPv4 TCP and perhaps UDP
protocols, as a means of enabling NAT boxes to serve more hosts from a
single IPv4 address.
Correct, and so provide a basis for a CEE architecture to be built on
it.
The NAT shortage is the initial pressing problem that gets the basic
option in the field and deployed widely. Further protocols, offering
further facilities, such as core-separated multi-homing, can then be
layered on top.
This doesn't solve the routing scaling problem in any way. It is
an attempt to cope with a situation where there is such a shortage
of IPv4 space that there's not enough to run NAT boxes with
whatever limitations they have from the current 16 bit TCP/UDP port
numbering system.
I think you must have stopped reading that blog post about half way
through, or you skimmed it :).
I don't understand your reasoning - and I can't see where you have
explained your reasoning.
I was proposing something more than just NAT. Specifically, I was
describing a path of least-resistance toward a "core/edge separated
internet, using rewriting" (CEE, right?), where the first step on
that iteration of hacks is "make NAT work for higher number of
hosts". Further, this proposal remains backward compatible with the
existing IPv4 network, to a greater degree than other CEE proposals
at least.
I think perhaps you may not have read the latter parts of that blog
post. (My writing style is dry, dull and sucks generally, so I can
understand you'd have fallen asleep a paragraph or two in! ;) ).
establishing communications - with more management packets flowing back
and forth etc. Arguments against doing this are in:
Today's "IP addr. = ID = Loc" naming model should be retained
http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html
The signalling overhead of an end-host<->end-host multihoming
proposal is a concern. However, you have the same problem with the
map-encap proposals - the signalling has to be done somewhere. You
can do it on x hosts, or x/y middle-boxes.
It seems there's a compromise we have to pick between:
- carrying information about peripheral^Wedge networks in the core
routing protocol
- carrying information about peripheral networks in packets *over*
the core routing protocol.
To my feeble mind, I don't see any way for protocols alone to
*reduce* the amount of signalling required, for a given amount of
information about edge networks.
The only way to reduce that information is to organise the edge
networks some way, e.g. through an administratively imposed hierarchy
(aggretation by geography, IX, whatever), or by some clever dynamic
organisation. I see that as an orthogonal matter to the protocol
question, and one best left at the door to this WG.
Please take a look at the graphs here:
CES & CEE are completely different (graphs)
http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html
Those graphs are your opinion, rather than based on data :). If
you're right, then CES will see deployment. We don't need to have a
speculative argument about it here.
If you disagree with this, then please write why.
If would move access customers to NAT, and use the reclaimed
addresses for services that need it. If I were part of a community of
ISPs I would start looking at cross-organisation reclaiming of
ineffectively used addresses. A free market in IPv4 addresses may
well develop to allow organisations to put a price on the cost of
renumbering Vs the cost of not having public IP space, and so
facilitate reclaiming. If I were an ISP, I would do all these things
well before deploying CES.
As I wrote earlier, it is quite plausible that such address space
recyling will serve the needs of the IPv4 internet for quite a while
- at least long enough for the NAT problem to become a pressing one
to solve.
And as I wrote in blog post, solving the NAT problem can provide the
immediate benefit to get an extension widely deployed that can then
be used as the basis for a CEE architecture.
Small incremental steps.
CES involves adding some things to the network. This is easier than
changing all the apps.
Experience with IPv6 suggests otherwise.
It's 15 odd years now, and the inter-network still does not generally
support IPv6. Despite the lack of IPv6 network service, the end-host
software *did*, to a significant degree, get upgraded.
Granted, CES doesn't require the fork-lift upgrade that IPv6 does.
But still, it assumes that ISPs will choose to add relatively complex
CES control plane - which implies administrative overheads, which
implies increased staffing costs - over the tried, tested and simple
NAT box + reclaiming address space.
Anyway, we can't resolve this argument without data. The market will
provide that in time.
But increasing the number of hosts a NAT box can handle from a
single IPv4 address has nothing to do with the routing scaling
problem, or multihoming, portability, inbound TE or mobility.
I respectfully submit you have considered only the initial part of my
argument :)
I will of course reread yours to see what of it I have missed.
Unfortunately it couldn't become even a little popular since it is
impractical to use it through the DFZ, or probably with most
routers.
I don't buy that. The same thing applied to IPv6 at one stage, indeed
it was worse with IPv6 for the DFZ couldn't forward IPv6 /at all/.
IP options being slow would be resolved within about 1 life-cycle of
routers (at least, their line cards) on the DFZ. I don't have
anything but anecdotal evidence as to what that is, my best guess is
circa 5 years.
Its not just slow - it involves such packet loss rates that
communication would be impractical. Even being slow would be
enough to ensure no-one wants it.
They found significant problems with about 15% to 21% of the paths
they tried. So 80% odd of the 210 paths they tried were fine. Plus we
need further studies to see how peculiar these loss rates were to the
set of paths they measured.
It's a problem, sure, but it doesn't quite seem as bad as you've
stated it. We face similarish connectivity problems trying to recycle
addresses when address ranges have been listed in bogon space, or
with low address ranges that historically have not been used and
which have ended up being used privately in places. E.g. what
proportion of paths have PMTU problems (which would affect CES - I
have to read your link still).
There isn't any perfect solution, it seems. This is about choosing
between problems.
But until such upgrades are done, there's no way anyone can
reliably communicate across the IPv4 DFZ with a new kind of
protocol, or with IPv4 packets with option headers.
It would take a similar time-scale to start to get IP extensions
deployed in end-hosts.
Once we can contemplate such upgrades to DFZ and other routers, then we
could do a CES architecture (Ivip) without encapsulation:
http://tools.ietf.org/html/draft-whittle-ivip-etr-addr-forw-00
As you note in the "pjakma said" addition to your page:
http://pjakma.wordpress.com/2010/02/12/making-the-internet-scale-through-nat/
your proposal would also depend on upgrading applications. I agree
with your assessment of this aspect of your proposal "This is the
most obviously crack-full part of it all."!
Indeed.
But again, it can be deployed in stages, and each stage can bring
some immediate benefits, while enabling the next stage. No single
stage solves all the problems, but after a number of iterations more
and more problems can be solved.
I'm not saying this is /better/ than map-encap solutions, just saying
that if for some reason map-encap doesn't gain traction either that
there is still a possible engineering path to a rewrite-based n-layer
routing architecture.
Just saying..
regards,
--
Paul Jakma p...@jakma.org Key ID: 64A2FF6A
Fortune:
Having the fewest wants, I am nearest to the gods.
-- Socrates
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
