Subject: Re: [arch-d] On identifiers: what is virtual and what is global ...

From: [email-masked] (Noel Chiappa)
Date: Mon, 27 Nov 2006 12:11:27 -0500 (EST)

> From: David Conrad <[email-masked]>

    > Pre-CIDR IP address allocation was FCFS with no relationship to any
    > sort of location information. The values allocated by "The NIC" were
    > simply flat routed 32 bit "names". This obviously made aggregation
    > hard. When the Internet became popular, it should have surprised no one
    > that we started to run into routing scalability problems -- there was
    > no way to hide information via aggregation.
    > So we came up with (and deployed in the nick of time) CIDR. 

Minor historical correction, which I'll package up with a more substantive
reply to someone else.

Subnets, which long preceded CIDR, were designed to do exactly the same thing
- localize the scope of routing data, and aggregate routing data outside that
scope. Yes, the original motivation of subnets was back in the days of
class-A addresses only (~1978), and its original motivation was to deal with
limits on network numbers. However, by the time it was widely adopted, A/B/C
had arrived, and at that point people were going with subnets - as opposed to
a flock of C's - to minimize pollution of the "default-free" (although we
didn't call it that, back then) routing tables. (Anyone else remember the
PDP-11 core routers, and the size limits on their routing tables? :-)

So CIDR was really just an attempt (among other issues, such as efficient
allocation of address space, e.g. running out of class B's) to add *another*
layer(s) of aggregation. I don't know how well it has worked, outside of
provider-based addresses, though; as far as I can tell, not a lot of
aggregation happens above an individual ISP.

    > From: "Bound, Jim" <[email-masked]>

    > this only addresses the multihoming problem and the question is if that
    > is addressed in this manner per the IAB Report does this buy us more
    > time to work on the routing?

If we can de-couple the routing-names (whatever they turn out to look like)
from anything except saying *where* in the network's connectivity patterns
the thing they name is, then yeah, that's a major, necessary step to solving
any routing problems one wants to tackle.

	Noel

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: John Day <[email-masked]>
Date: Mon, 27 Nov 2006 16:53:37 -0500

Noel is right about the original idea behind Classes A, B, and C. 
But at some point we started handing out Bs and Cs with no regard to 
"where" they were.  The majority of Class As were at best at an 
organizational level and even before that most blocks that providers 
had were for their internal use and small customers.  Most customers 
then tried to get their own IP addresses which bore no relation to 
anything.

While it was an attempt, it seems it broke down fairly soon.

John

---

From: Vince Fuller <[email-masked]>
Date: Mon, 27 Nov 2006 17:02:19 -0800

> aggregation happens above an individual ISP.

At the risk of more digression into ancient history, I'll expand on the above
a little bit. First, a little context: CIDR was a product of the ROAD group,
chartered in 1991 with the task of dealing with issues surrounding the scaling
of Internet ROuting and ADdressing. The group identified three issues, later
referred to as the "three trucks that would run us over":

  1. Running out of "Class-B" networks (blocks of /16's in the range 128/8
     through 191/8)
  2. Apparently-exponential growth in the number of routable prefixes
  3. Eventual exhaustion of the 32-bit address space

Supernetting (RFC1338) and is successor, CIDR, was primarily aimed at solving
problem #1, the most pressing at the time, without making problem #2 worse
(the only pre-CIDR alternative to a "Class B" was a block of "Class Cs",
which vastly increased the number of globally-visible routing table entries).
CIDR's first goal when conceived was simply to allow prefixes of sizes other
than /8, /16, and /24 to be used (this was sometimes known as the "three
bears" - /8 was too big, /24 was too small, but /16 was "just right" in the
minds of many). As it was refined, aggregation to help with problem #2 became
more appealing; the availability of more flexible address assignment blocks
also took some heat off of problem #3. CIDR was intended as a short-to-medium
term fix in the face of urgent problems; the members of the ROAD group fully
expected a more long-term solution (the ipng effort) to be developed and
deployed within 5 to 10 years. Unfortunately, it seems that we were
excesseively optimistic.

For more historical description, check out "The Long and Windy ROAD" at
http://rms46.vlsm.org/1/42.html.

	--Vince

P.S. FWIW, my original thinking about CIDR was inspired by a presentation
     that you gave about CLNS addressing at the 19th IETF in Boulder, CO,
     back in December, 1990. Attached is the original piece of email that
     I sent to the ROAD in January, 1992, describing my thoughts. I also
     have vague recollections of discussions about Supernetting between
     Jessica Yu, Kannan Varadhan, and me (I don't recall Tony Li being there
     as he wasn't a regional net operator) at an NSFNET Regional Techs
     meeting in Ann Arbor probably 6 months before or after that email and
     the subsequent Tucson ROAD meeting in February, 1992.
_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Nov 2006 10:22:51 +0100

Noel,

> aggregation happens above an individual ISP.

But that itself is an enormous win - scaling like the number of ISPs
is much more reasonable than scaling like the number of end user sites,
which was the pre-CIDR situation.

And to restate the obvious, current multihoming practice puts us right
back to scaling like the number of end user sites.

    Brian