Minutes interim-1992-iesg-09 1992-04-02 17:00
minutes-interim-1992-iesg-09-199204021700-00

    IETF STEERING GROUP (IESG)

    REPORT FROM THE TELECONFERENCE

    April 2nd, 1992

    Reported by: Greg Vaudreuil, IESG Secretary

    This report contains

    - Meeting Agenda
    - Meeting Attendees
    - Meeting Notes

    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.