Brian E Carpenter <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|...
|> |I wasn't around then, but from what I have been told and read I think
|> |everyone was very aware of the scaling issues. But decided to put them
|> |forward and buy time.
|>
|> Well, I was around and I don't recall any major concern.
|
|This is hard to reconcile with some of the words in RFC 1380,
|or what I remember when I first arrived in late 1992.
IMHO, by the time 1380 was published in 1992, RFCs were not quite the
reflection of community feeling that they had once been. RFC1380 was an
attempt to highlight the problem and encourage the concern as much as it was
an expression of that concern. Note that while 1380 does brief lip service to
other possible solutions (including a distributed one!), it quickly concludes
without proof that aggregation must be part of any long-term solution. At
least that's the most obvious reading of a sentence that isn't quite English...
|My recollection
|is of a consensus to buy time with CIDR.
There was a consensus to use provider-based hierarchical allocation as a
temporary fix for a projected problem. Unfortunately, there was some confusion
about how much time we were trying to buy and exactly what we were buying that
time for.
Initially the plan was presented as just that: hierarchical *allocation* by
providers to end users. The addresses so allocated were to be portable and
were to belong to the end user. The theory was that this would slow routing
table growth, but would ultimately put us right back where we started once
enough people changed providers and took their addresses with them. This
scheme was perfectly consistent with the notion of "buying time" and it was
not going to be a serious burden for end users.
Very soon the "allocations" from providers turned into loans (or, at the low
end, rentals). It was quickly pointed out that the original notion of letting
users take their addresses with them "didn't scale". Suddenly we weren't just
buying a little time, we needed to buy indefinite time until some new routing
mechanism could be implemented. But since provider control of addresses worked
out so well (at least for everyone but new end users) we never saw much effort
go into developing that new routing mechanism.
Eventually it turned out that what had really been meant by "buy time" was to
put off the problem until a new next generation protocol suite could be built.
There had never been any intention to return to portable v4 addresses. At
least not in retrospect.
Now here we are a decade later deploying the next generation of IP and we
just need to "buy some time" with provider-based hierarchical address loans.
What have we done with all the time we already bought? We didn't do anything
to restore portable v4 address allocations. We have a new protocol suite, but
it suffers from exactly the same limitation in this respect as v4. What will
we do with more time? Some people are quick to point out that we don't have a
clue how to solve the problem and that we don't even know how we should be
approaching it. If this is true then we might as well be honest and admit that
we aren't just "buying time" anymore: IPv6 really is just IPv4 with more
address bits.
|(Just as PA addressing in IPv6
|buys time; this was in fact strongly debated during the formative
|stage of IPng in 1993/94.)
Yes, it was strongly debated. Given how long it has taken for v6 to go
anywhere, the arguments that there just wasn't time to do anything better
initially look less than convincing. In retrospect.
I would like to know specifically for what we are buying time with PA addressing
in v6, and just how much time we are trying to buy. Absent a visible plan it
seems that we will merely repeat the v4 scenario. We will buy time with PA
addressing until there is no longer any possibility of getting rid of it.
Contrary to the popular quip, it is not easier to go from aggregated to non-
aggregated than the reverse--especially if the transition requires any change
in the deployed code.
|> We were aware
|> that there might ultimately be a problem but we were much more open-minded
|> about solutions relying both on faster hardware and on new protocols. I
|> think that's why some (a lot?) of us were more than a little annoyed at
|> being sandbagged by the "CIDR" two-step. What was supposed to be a temporary
|> fix quickly evolved into the effective extinction of new portable addresses.
|> Since then, hierarchical allocation has become so ingrained that some people
|> have trouble even conceptualizing other solutions.
|
|It's true that RFC 1380 assumed hierarchical allocation. But it also
|clearly expressed the distinction between interim solutions (specifically
|CIDR) and the long term.
It made a distinction between the solutions and then asserted without evidence
that any long-term solution had to involve aggregation. By strange coincidence
that was the short-term solution as well. I'm sure we could argue the exact
semantics of "aggregation" at great length, and certainly in the most abstract
sense of summarization it could mean simply that you have to be able to start
from *something* and eventually figure out how to route a packet. For such a
definition of aggregation the claim that aggregation is necessary is a truism
devoid of substance, so I doubt that that is what was intended.
|What I think it missed was the whole topic
|of identifier/locator separation. That seems to be what we (for
|some definition of "we") need to focus on now.
I've been trying to focus attention on portable identifiers (which are really
just a thinly disguised form of source routing) for years. There seem to be
several issues that keep getting in the way:
-It is highly unlikely that any solution along the lines of a separate
identifier is going to be totally without cost. If we accept the view
that any cost is too great then clearly portable identifiers are DOA
regardless of the details of the proposal. So I again suggest that we
try to reach consensus on how much (if anything) it is worth to us to
provide end users with some sort of identifier that is independent of
the locator.
-It has been suggested that we already depend strongly on being able to infer
topology hints from identifiers, even at high levels (i.e., in applications).
This is of course anathema to the very goal of making an identifier independent
of the locator. Clearly it would be possible to make both the identifier and
the locator available to applications, but again this is not going to happen
without cost. We should decide whether we really need this and how much we
are willing to pay for it.
-There seems to be some sentiment that any solution to the portable identifier
problem must also solve all other related problems and do so optimally--right
away. I think that this is completely backwards. Even a partial solution now
that puts in the hooks for further development is better than nothing. As it
stands, there is nothing in v6 that makes it more amenable to a separation of
identifier and locator than is v4. The only advantage we have (if indeed we
still have it) is early access. If we buy time for v6 deployment with PA we
will again be in the position of having to wait for another new next generation
protocol to solve the problem.
|I don't think most people whose BGP tables were exploding felt in the
|least sandbagged by BGP4.
Of course not; by and large they were the ones doing the sandbagging.
Aggregation offers many benefits to providers (increased life for cheaper
hardware and address rental revenues being chief among them) at the expense
of end users. Sure, there were some end users taking full BGP feeds and
they may have been happy to put off a router upgrade. (There were also
plenty of users who already had or could quickly get all the portable address
space they thought they would need. The transition was of little concern to
most of them, though you can bet they won't give up that space now for PA v6
addresses.) But I don't think there is any serious debate about where most of
the benefit accrued.
Dan Lanciani
ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
