Please contact IESG Secretary Greg Vaudreuil for more information.
ATTENDEES
---------
Almquist, Philip / Consultant
Borman, David / Cray Research
Chiappa, Noel
Crocker, Dave / TBO
Coya, Steve / CNRI
Davin, Chuck / MIT
Gross, Philip / ANS
Hinden, Robert / BBN
Hobby, Russ / UC-DAVIS
Piscitello, Dave/ Bellcore
Stockman, Bernard / SUNET/NORDUnet
Vaudreuil, Greg / CNRI
Regrets
Crocker, Steve / TIS
Estrada, Susan / CERFnet
Huizer, Erik / SURFnet
Reynolds, Joyce / ISI
AGENDA
------
This teleconference was designated as a single topic conference to
discuss and craft a plan for implementing an IETF Routing and
Addressing development strategy.
MINUTES
-------
The meeting began with a review of the timeframe the various
solutions to the Routing and Addressing problems will be needed.
For the ROAD effort, Phill Gross (and others) had investigated the
growth rate of various Internet metrics, such as networks in the
Merit Policy Routing Database, Assignement of IP network numbers, AS
numbers, hosts, and DNS names. He was unable to send the detailed
graphs, but did describe the growth trends.
Based on the NSFnet Routing Database, the following timeframes were
estimated:
Class B Address exhaustion: ~ 2 Years ~30,000 configured Routes:
~ 2.5 Years IP address exhaustion: ~ 5 Years
The rate of growth of the class B addresses in the Merit database
appears to be slowing. It is not clear how this relates to the rate
of address assignment. There is some indication that number of
unconnected networks is rising.
At this point the following amount of the address space is used.
Assigned Available
Class A 50 128
Class b 7,500 16,384
Class C 30,000 2,097,152
The IESG discussed two of the sort term addressing proposals in terms
of their time to deployment and useful life.
C Sharp
The C Sharp (C#) proposal calls for grouping the remaining C address
space into a new class of networks with a larger host space This
aggregation will not require hosts to recognize a change in class C
addresses. No mask is necessary for a host to differentiate between
the host and network portion of an address. Changes will be
required to routers to recognize the new class of addresses. These
changes are seen as a minor extensions to the current "classful"
environment, and are seen as easy to add to current router
software.
This proposal does not provide for, nor does it prevent the
aggregation of routing information and as such makes no improvement
in the routing table size. C# "costs" a bit and reduces the
effective number of class "C" networks by half.
Classless Interdomain Routing (CIDR)
The CIDR proposal calls for the elimination of the address class
concept. By adding network address masks to interdomain routing
protocols, networks can be assigned and aggregated efficiently to
reduce the routing table size in transit network routers. This
proposal allows both the aggregation of Class C networks into larger
more useful networks and the splitting of class A networks into
smaller, less wasteful networks.
Because CIDR addresses require a address mask to understand which
portions of an address are significant, it may either require
changes to hosts to enable them to recognize address masks, or
require careful engineering of network number assignment such that
old-style hosts interpreting addresses as "classfull" won't get
confused. The interpretation of the all 1's network broadcast is
one such case.
If CIDR is used solely for aggregation of existing classes of
networks, no changes will be required for hosts. This reduces the
utility of CIDR significantly in that Class "A" and Class "B"
networks cannot be broken into smaller chunks. If not applied to
Class "B" addresses CIDR will not help extend the life of the nearly
exhausted Class "B" addresses.
The Questions
C# and CIDR are not exclusive. Both can be implemented
simultaneously. The decision point lies in the timeframe the
solution is expected to be used. If aggregation is needed in the
immediate short term, there is no choice but CIDR Supernetting.
A small survey of router vendors seems to indicate that current
products with memory additions will handle up to 16,000 routes. In
the near future, it is likely routers will be able to handle 35,000.
Does this "more thrust" buy enough time to pursue the "long term"
solution without requiring subnetting of Class A and B Via CIDR?
How long will it take to implement and deploy the "real" solution,
and will either c# and/or the CIDR supernetting last until then?
ACTION: Gross, Chiappa -- Further investigate the anticipated
capabilities of current and next generation routers with respect to
routing table size.
The IESG discussed available mechanisms and what problems they addressed.
Solutions Matrix
| Rout | Class B | IP Exhaustion
-------------+---------+---------+-------------
C-Sharp | | x |
-------------+---------+---------+-------------
CIDR | x | x |
-------------+---------+---------+-------------
More Thrust | x | |
-------------+---------+---------+-------------
Recycling | | x |
-------------+---------+---------+-------------
IP encaps x | x | x
-------------+---------+---------+-------------
ISO encaps | x | x | x
-------------+---------+---------+-------------
Simple CLNP | x | x | x
-------------+---------+---------+-------------
Expected Timeframes
| : : :
More Thrust |@@@@@ : : :
| : : :
Recycling |@@@@ : : :
| : : :
Class C-Sharp | @@@@@: : :
| : : :
CIDR | @@@@@@@@@@@@@@@@ : :
| : : :
IP Encaps | @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ :
| : : :
Simple CLNP | : @@@@@@@@@@@@@@@@@@@@@@@@@@@@
| : : :
CLNP Encaps | : @@@@@@@@@@@@@@@@@@@@@@
| : : :
+-------+---------------+---------------+----------- Time
Class B IP Need
Exhaustion Exhaustion 10**9
nets
Work Plan
There are currently several efforts at extending protocols for CIDR
Supernetting underway. BGP version 4 is being defined in the BGP
working group. Dual IDRP is being developed, and Interdomain Policy
Routing is defined to support classless routing. The IESG
encourages this work to continue.
IP encapsulation, ISO encapsulation (one method of implementing
CNAT), and CIDR all require that IP addresses be assigned in
"blocks" to facilitate aggregation. The IESG recognized that each of
these approaches required an IP addressing plan that supported
aggregation. At least the following need to be part of developing an
IP addressing plan: the IETF Internet Area, IETF Routing Area, IETF
Operational Requirements, FEPG, and IEPG.
Action: Gross -- Develop a plan for coordinating the development of an
address assignment strategy. Work with Chiappa, Almquist, and Hinden
in establishing the appropriate liaison.
The IESG did not recommend between CIDR and C# for sort term address
extensions at this meeting. However, there was a strong feeling
that activities needed to begin immediately, and that the IESG
needed to make recommendations on a work plan soon. The IESG asked
Philip Almquist to draft a strawman recommended work plan for IESG
to consider as its position.
ACTION: Almquist -- Using the work of the ROAD working group, and the
minutes of this meeting, draft a position for IESG review.
The IESG did not have adequate information to discuss the three long
term proposals, IP encapsulation, ISO encapsulation (CNAT), and
Simple CLNP.
