home *** CD-ROM | disk | FTP | other *** search
/ Internet Access: To the Information Highway / InternetAccessToTheInformationHighway1994.disc1of1.iso / internet / rfc4 / rfc1482.txt < prev    next >
Text File  |  1994-05-29  |  26KB  |  620 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                   Mark Knopper
  8. Request for Comments: 1482                      Steven J. Richardson
  9.                                                         Merit/NSFNET
  10.                                                            June 1993
  11.  
  12.     Aggregation Support in the NSFNET Policy-Based Routing Database
  13.  
  14. Status of this memo
  15.  
  16.    This memo provides information for the Internet community.  It does
  17.    not specify an Internet standard.  Distribution of this memo is
  18.    unlimited.
  19.  
  20. Abstract
  21.  
  22.    This document describes plans for support of route aggregation, as
  23.    specified in the descriptions of Classless Inter-Domain Routing
  24.    (CIDR) [1] and the BGP-4 protocol [2], by the NSFNET Backbone Network
  25.    Service.  Mechanisms for exchange of route aggregates between the
  26.    backbone service and regional/midlevel networks are specified.
  27.    Additionally, the memo proposes the implementation of an Aggregate
  28.    Registry which can be used by network service providers to share
  29.    information about the use of aggregation.  Finally, the operational
  30.    impact of incorporating CIDR and aggregation is considered, including
  31.    an analysis of how routing table size will be affected.  This impact
  32.    analysis will be used to modify the deployment plan, if necessary, to
  33.    maximize operational stability.
  34.  
  35. 1. Introduction
  36.  
  37.    The Internet network service provider community and router vendors
  38.    (as well as the IESG and various IETF working groups) have agreed
  39.    that the time for deployment of route aggregation is upon us. This
  40.    topic has been discussed in the BGP-D, NJM and ORAD working groups at
  41.    several IETF meetings; it was a discussion topic of the NSFNET
  42.    Regional Techs' Meetings in January and June, 1993; and it was also a
  43.    topic of several meetings of the Federal Engineering Planning Group
  44.    and Engineering and Operations Working Group of the Federal Network
  45.    Council.
  46.  
  47.    All have generally agreed that Summer, 1993 is the time to enable
  48.    BGP-4 and CIDR aggregation.  Each of the parties is responsible for
  49.    its own aspect of CIDR implementation and practice. This memo
  50.    describes Merit's plans for support of route aggregation on the
  51.    NSFNET, and a proposal for implementing a database of aggregation
  52.    information for use by network providers.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Knopper & Richardson                                            [Page 1]
  59.  
  60. RFC 1482              Routing Aggregation Support              July 1993
  61.  
  62.  
  63. 2. Aggregation Support by the Backbone Service
  64.  
  65.    The NSFNET backbone service includes a Policy-Based Routing Database
  66.    system which currently holds the set of network numbers that are
  67.    accepted by the backbone service with a list of Autonomous System
  68.    numbers from which announcements of these network numbers are
  69.    expected.  In order to implement CIDR, the database system will be
  70.    modified to allow aggregation of routing information to be
  71.    configured.
  72.  
  73.    The NSFNET will (initially) not support de-aggregation on its
  74.    outbound announcements. See section 2.3.
  75.  
  76. 2.1 Current Configuration Capabilities
  77.  
  78. 2.1.1 Inbound Announcements
  79.  
  80.    An example of the way a network number is currently configured is as
  81.    follows:
  82.  
  83.          35      1:237   2:233   3:183   4:266   5:267  6:1225
  84.  
  85.    This shows that network number 35 (ie. 35.0.0.0, a class A net
  86.    number) is configured on the T3 backbone such that routing
  87.    announcements are expected from up to 6 autonomous systems. The
  88.    primary path is via AS 237, secondary is via AS 233, etc.
  89.  
  90. 2.1.2 Outbound Announcements
  91.  
  92.    Currently the NSFNET database has a list of AS's or network numbers
  93.    for each neighbor AS that are announced by the backbone to that AS.
  94.    These announcements are specified currently by "announcetoAS"
  95.    statements--which implement policies submitted by midlevels to
  96.    Merit--and then included in the ANSnet router configuration files.
  97.    There are two forms of these statements.  The first form uses the
  98.    "norestrict" clause and indicates that all of the network numbers
  99.    within each AS in the list should be announced to the neighbor
  100.    midlevel AS. For example:
  101.  
  102.          announcetoAS 42 norestrict ASlist 22 26 38 60 68
  103.  
  104.    In this example, the NSFNET is configured to announce to neighboring
  105.    midlevel AS 42, all networks in the routing table that were announced
  106.    from AS's 22, 26, 38, 60 and 68.
  107.  
  108.    If the "norestrict" keyword is changed to "restrict", this indicates
  109.    that an explicit announce list of network numbers for the AS is
  110.    specified in the configuration file. The NSFNET will only announce
  111.  
  112.  
  113.  
  114. Knopper & Richardson                                            [Page 2]
  115.  
  116. RFC 1482              Routing Aggregation Support              July 1993
  117.  
  118.  
  119.    network numbers that were announced by the AS's in the list, *AND*
  120.    which appear in the "restrict list" of network numbers submitted
  121.    separately by the midlevel.
  122.  
  123.       For example,
  124.  
  125.          announcetoAS 42 restrict ASlist 22
  126.  
  127.          announce 192.135.237 <other info>
  128.  
  129.    These statements mean that AS 42 only wishes to hear announcements
  130.    from the backbone about the nets in AS 22 which are explicitly listed
  131.    here (i.e., net 192.135.237).
  132.  
  133.    It is also possible, when using the "restrict" keyword, to list
  134.    specific "noannounce" lines. Those indicate that all of the networks
  135.    listed in the routing table for the AS should be announced except
  136.    those listed on the noannounce clauses.  (There is also a
  137.    "noannouncetoAS" statement[4].)
  138.  
  139. 2.2 New Configuration Features for Aggregation
  140.  
  141.    There will be three new capabilities for which the backbone service
  142.    can be configured to support aggregation. The first two allow
  143.    aggregates to be accepted and stored in the backbone routing tables
  144.    based on announcements by the regional network (autonomous system or
  145.    AS) peers.  The third allows the announcement of aggregates to the AS
  146.    neighbor peers. The following sections give examples of the three
  147.    features.
  148.  
  149.    We use the notation <net-IP prefix-length> to describe an aggregate.
  150.    This refers to the IP prefix "net-IP", with a mask which has
  151.    "prefix-length" 1's as counted from the high-order end. For example,
  152.    <192.64.128 17> is equivalent to <192.64.128, 255.255.128.0> [5].
  153.    (The form using prefix-length rather than the mask is more compact.)
  154.  
  155. 2.2.1 NSFNET accepts aggregates
  156.  
  157.    In this case the regional peer router is CIDR-capable (i.e., runs
  158.    BGP-4) and the announcement comes into the backbone as an IP address
  159.    prefix.
  160.  
  161.    To illustrate this in the spirit of sec. 2.1.1:
  162.  
  163.          <192.64.128 17>         1:189 2:24 3:267
  164.  
  165.    In this example, independent of the "class" of IP network number, an
  166.    aggregate containing network addresses matching a pattern in which
  167.  
  168.  
  169.  
  170. Knopper & Richardson                                            [Page 3]
  171.  
  172. RFC 1482              Routing Aggregation Support              July 1993
  173.  
  174.  
  175.    the first 17 bits match the prefix 192.64.128 will be accepted in
  176.    announcements to the NSFNET service.  The primary path to
  177.    destinations covered by the prefix is expected via AS 189, the
  178.    secondary, via AS 24, etc.
  179.  
  180. 2.2.2 NSFNET aggregates by proxy
  181.  
  182.    The other method of incorporating CIDR aggregate announcements into
  183.    the backbone routing tables is that of aggregation by proxy.  In this
  184.    case, the backbone is configured to perform aggregation on behalf of
  185.    a peer AS which is not configured to announce the aggregate to the
  186.    backbone (i.e., an AS which does not connect to the backbone via a
  187.    CIDR-capable peer).
  188.  
  189.    An example of this aggregation technique is:
  190.  
  191.          proxy <192.64.128 17>     1:189  2:24  3:267
  192.                  if  <192.64.192 24>
  193.                  or  <192.64.129 24>
  194.                  or  <192.64.167 24>
  195.  
  196.    (Note: the syntax used in this document is arbitrary and is only used
  197.    to illustrate the method. The syntax to be used in actual routing
  198.    requests is to be determined.)
  199.  
  200.    In this example, the aggregate <192.64.128 17> will be stored and
  201.    propagated within the backbone as an aggregate under a set of
  202.    conditions.  Initially, the GateD support will allow an "OR" list of
  203.    conditions such that if one of the aggregates in the list matches the
  204.    proxy aggregate will be stored[6].  For the case above, this means
  205.    that, if any of the CIDR aggregates:
  206.  
  207.          <192.64.192 24>
  208.          <192.64.129 24>
  209.          <192.64.167 24>
  210.  
  211.    (which--under the current, class-based IP address system--are
  212.    equivalent to the class C net numbers 192.64.192, 192.64.129, or
  213.    192.64.167, respectively) is heard, the backbone router will act as
  214.    though it heard the announcement of the single CIDR aggregate
  215.    <192.64.128 17>.
  216.  
  217. 2.2.3 NSFNET announces aggregates
  218.  
  219.    The functionality of the current system, as outlined in sec. 2.1.2,
  220.    above, will continue to exist once CIDR is implemented. The
  221.    "norestrict" function (or its equivalent in the new software) will
  222.    specify that all network reachability information received from a set
  223.  
  224.  
  225.  
  226. Knopper & Richardson                                            [Page 4]
  227.  
  228. RFC 1482              Routing Aggregation Support              July 1993
  229.  
  230.  
  231.    of Autonomous Systems, including any aggregates, will be announced.
  232.    It should also be possible to use to the equivalents of the
  233.    "restrict" keyword and the "announce" (or "noannounce") statement in
  234.    order to limit the announcements of the aggregations within an AS to
  235.    any desired subset.
  236.  
  237. 2.3 Specifically Unsupported Capabilities, Limits of Initial Deployment
  238.  
  239.    There are some aspects of aggregation which will specifically not be
  240.    supported in the initial deployment of CIDR capabilities on the
  241.    NSFNET backbone.  In particular, when the NSFNET service announces
  242.    routes to midlevel peers, de-aggregation will not be performed [3].
  243.    Therefore, a peer which needs to receive full routing information
  244.    should run a protocol which supports CIDR (initially, BGP-4; later,
  245.    IDRP). Peer networks using default routing will be able to reach
  246.    networks that are part of aggregated routing information across the
  247.    backbone (as in section 6.4 of [3]).
  248.  
  249. 3.  CIDR Aggregate Registry
  250.  
  251.    In discussions with network service providers, it has become apparent
  252.    that there is a great need for sharing of aggregate information; this
  253.    is necessary to fulfill the coordination referred to in sec. 2.3.
  254.    Beyond the need to implement CIDR aggregation facilities in the
  255.    NSFNET Policy-Based Routing Database (as described in section 2),
  256.    there is a clear need to have a separate database which will allow
  257.    aggregate information from any Autonomous System to be stored and
  258.    made available for easy electronic retrieval. This information can be
  259.    used for routing coordination and policy configuration in the larger,
  260.    non-NSFNET-centric, inter-domain context.
  261.  
  262.    One of the expected uses of such a database is to help determine, as
  263.    CIDR matures, the granularity of aggregation of network reachability
  264.    information with respect to policy.  The useful scope of aggregation
  265.    is the subject of much discussion[5][7], and will be influenced by
  266.    such considerations as how network number allocation has been
  267.    handled, and whether the network provider has renumbered its client
  268.    networks to conform to CIDR aggregation boundaries. Rules and issues
  269.    regarding network number allocation with CIDR are discussed in [8]
  270.    and [7].
  271.  
  272.    In order further these goals, Merit proposes to implement a "CIDR
  273.    Aggregate Registry" to provide sharing of aggregate information for
  274.    the Internet inter-domain routing community. Initially, this will be
  275.    a simple database without much structure. It is not intended to hold
  276.    only aggregates which are announced or accepted by the NSFNET
  277.    service; rather, it should be a community registry that all will be
  278.    invited to use and make use of.
  279.  
  280.  
  281.  
  282. Knopper & Richardson                                            [Page 5]
  283.  
  284. RFC 1482              Routing Aggregation Support              July 1993
  285.  
  286.  
  287.    The Aggregate Registry will consist of a list of aggregate
  288.    announcement statements. Each statement consists of four types of
  289.    information, along with contact information:
  290.  
  291.       1) CIDR Aggregate: The aggregate identifier, consisting of a
  292.       network number prefix and the prefix length. For example,
  293.       <192.29.128 16>.
  294.  
  295.       2) Home AS: The source AS number for the aggregate. That is, the
  296.       AS number of the network service provider that initially
  297.       aggregates the network reachability information into the aggregate
  298.       for announcement to its neighbors.
  299.  
  300.       3a) Announcing AS: An AS number that announces this aggregate to
  301.       its neighbor AS's.
  302.  
  303.       3b) Neighbor AS list: A list of neighbor AS's to whom the
  304.       aggregate will be announced by the AS named in 3a.
  305.  
  306.       4) Contact information: eg. e-mail address and name or NIC handle
  307.       of the administrative and technical contacts for the source AS.
  308.  
  309.    Thus, a given aggregate is listed once as announced by its source AS.
  310.    It may then be listed once again per transit AS which announces the
  311.    aggregate downstream to its neighbors.  For example, the CIDR
  312.    aggregate <199.29.128 16> could be listed as:
  313.  
  314.           CIDR aggregate  home ann  neighbor
  315.           (prefix-length) AS   AS   AS list         contacts
  316.          -----------------------------------------------------------
  317.          <199.29.128 16>  100  100  200 201 690     fred@nowhere.net
  318.          <199.29.128 16>  100  690  266 267 1225... <contact info>
  319.          <199.29.128 16>  100  200  297 372         <contact info>
  320.          <199.29.128 16>  100  201  771 1262        <contact info>
  321.  
  322.          Note: This can be represented using the syntax used for objects
  323.          in the RIPE-81 paper[9].
  324.  
  325.    Here, AS 100 (the source AS) performs any aggregation and announces
  326.    the CIDR aggregate <199.29.128 16> to neighbor ASs 200, 201, and 690.
  327.    In turn, AS 200 announces this same aggregate to its neighbor ASs 297
  328.    and 372; further lines show announcements of the given aggregate by
  329.    AS 690 and AS 201.
  330.  
  331.    Note that this registry reflects both the simple list of aggregates
  332.    that are supported by the union of network providers, as well as
  333.    information on inter-domain topology for the Internet.  Merit will
  334.    implement procedures for registering any network provider's
  335.  
  336.  
  337.  
  338. Knopper & Richardson                                            [Page 6]
  339.  
  340. RFC 1482              Routing Aggregation Support              July 1993
  341.  
  342.  
  343.    aggregates in the Registry; for those CIDR aggregates carried over
  344.    the NSFNET backbone, Merit will implement procedures for integrating
  345.    this Registry with the process of updating the aggregate routing
  346.    announcements.  Requests to update the information will be handled
  347.    via e-mail or on-line registration tools.
  348.  
  349. 4. Effects of CIDR on Operational Aspects of the Internet
  350.  
  351.    The introduction of CIDR will clearly necessitate various changes
  352.    beyond the introduction of new router software.  In particular, Merit
  353.    and other network service providers will have to adjust tools,
  354.    reports, and procedures as CIDR is implemented and evolved, and these
  355.    changes will have to be coordinated in order to ensure a smooth
  356.    transition to the CIDR-capable Internet.
  357.  
  358.    While this document is by no means exhaustive, some of the areas
  359.    affected are discussed briefly below; what is intended is to foster
  360.    an awareness of some these changes, so as to initiate thinking about
  361.    and planning for this transition.  While it is obvious that CIDR and
  362.    policy routing imply greater coordination of many operational
  363.    matters, it is not clear how profoundly this will affect the day-to-
  364.    day running of the Internet.
  365.  
  366.    (Note:  Aspects of the actual phased deployement of CIDR are covered
  367.    in [3] and [10].)
  368.  
  369. 4.1 NSFNET Configuration Files and Reports; Neighbor AS Configurations
  370.  
  371.    The addition of CIDR capability to the NSFNET Policy-Based Routing
  372.    Database, as outlined in sec. 2, will require the updating of at
  373.    least the following reports which are currently produced by Merit
  374.    (and available via anonymous FTP from nic.merit.edu):
  375.  
  376.          ans_core.now  as-site.now  country.now net-comp.now  net-net.now
  377.          net-ter.now   non-us.now
  378.  
  379.    Any tools which access this information, such as the various clients
  380.    or scripts released by Merit or developed by others, will have to be
  381.    changed.
  382.  
  383.    However, the most striking change will be in the transition from
  384.    rcp_routed to GateD; it is very different in important particulars,
  385.    and follows different conceptual principles [11].
  386.  
  387.    Network providers which develop any part of their configuration files
  388.    from parsing the NSFNET configuration files or reports *MUST* plan
  389.    for these changes in order to help themselves and the Internet
  390.    community achieve a smooth transition to CIDR.
  391.  
  392.  
  393.  
  394. Knopper & Richardson                                            [Page 7]
  395.  
  396. RFC 1482              Routing Aggregation Support              July 1993
  397.  
  398.  
  399. 4.2 Routing and Administrative Policies
  400.  
  401.    In this document, Merit has stated its commitment to supporting CIDR
  402.    through both changing policies related to administering the NSFNET
  403.    and developing a CIDR Aggregate Registry for the broader Internet
  404.    community.
  405.  
  406.    In addition to these changes, here are some of the other policies,
  407.    administrative and routing, which must to be coodinated in order to
  408.    achieve optimum benefits of CIDR:
  409.  
  410.       - policies of the InterNIC and of network service providers in
  411.         assigning (CIDR) IP nets and blocks, as mentioned above;
  412.  
  413.       - policies of the various ASs in coordination of transit and other
  414.         routing policies;
  415.  
  416.       - policies of registration of new networks, from the InterNIC or
  417.         network provider, through the CIDR Aggregate Registry, etc.;
  418.  
  419.       - policies related to coordination of routing changes;
  420.  
  421.       - coordination of routing policies, in general, to avoid new
  422.         classes of routing problems due to new methods of routing.
  423.  
  424. 4.3 Realtime Issues
  425.  
  426.    Issues which have not been examined in detail are:
  427.  
  428.       - debugging of routing/connectivity problems;
  429.  
  430.       - stability and other properties of routing under various
  431.         scenarios of CIDR configuration and network topology;
  432.  
  433.       - explicit specification of routing decision algorithms to avoid
  434.         routing anomalies;
  435.  
  436.       - increased network load due to packets traversing an AS, such as
  437.         the NSFNET backbone, before being discarded due to addressing a
  438.         "hole" in a CIDR aggregate.
  439.  
  440. 4.4 Estimate of Reductions in Routing Tables
  441.  
  442.    An argument in favor of the implementation CIDR is the effect which
  443.    it should have upon the NSFNET and other routing tables [1] [5].  The
  444.    burning question is: What is the magnitude of this effect?  In view
  445.    of the various issues to be dealt with, this is an important
  446.    consideration.
  447.  
  448.  
  449.  
  450. Knopper & Richardson                                            [Page 8]
  451.  
  452. RFC 1482              Routing Aggregation Support              July 1993
  453.  
  454.  
  455.    In terms of the immediate savings in reduction of the NSFNET backbone
  456.    routing tables, if a set of aggregates were done all at once, a
  457.    recent calculation--which might be characterized as an optimistic
  458.    estimate using a pessimistic algorithm (it looks for the longest
  459.    continuous block of addresses announced to the NSFNET backbone)--
  460.    yields [12]:
  461.  
  462.         861 size  2 saving  861 announcements
  463.         286 size  4 saving  858 announcements
  464.         117 size  8 saving  819 announcements
  465.          67 size 16 saving 1005 announcements
  466.          13 size 32 saving  403 announcements
  467.           3 size 64 saving  189 announcements
  468.        1347 total   saving 4135 announcements of 12348 (33%).
  469.  
  470.    Here, the first column represents the number of CIDR aggregates of
  471.    the given "size," and shows the corresponding reduction in net
  472.    announcements due to the adoption of this aggregate.  (A CIDR
  473.    aggregate of "size <n>" is one which encompasses <n> class A, B, or C
  474.    networks; the 67 "size 16" CIDR aggregates actually combine
  475.    announcements for 16 separate networks into a single net aggregate.)
  476.    It is unclear, at this time, whether or not the true savings would be
  477.    of this magnitude, but the extended report provides a basis for
  478.    discussion [12].
  479.  
  480.    The other aspect of impact upon the routing tables, the reduction in
  481.    the rate of growth (and the concomitant slowing of the rate of
  482.    exhaustion of IP address space), is an entirely different matter.
  483.    Simple calculations related to the rate of class B address space
  484.    exhaustion indicate that CIDR-conformant policies of the InterNIC
  485.    with respect to address assignment is helping [1].
  486.  
  487.    Clearly, more detailed analysis is desirable in order to better
  488.    understand the realistic gains of the CIDR deployment process, both
  489.    initially and in the longer term.
  490.  
  491. 5.  Conclusions and Next Steps
  492.  
  493.    Implementation of CIDR is underway, but there is still a fair amount
  494.    of planning and discussion that is needed for a successful
  495.    transition.  Merit is proposing specific functions for CIDR
  496.    aggregation that will be supported by the NSFNET, as well as a CIDR
  497.    Aggregate Registry that can serve as the basis for inter-domain
  498.    routing coordination.
  499.  
  500.    The Aggregate Registry will allow a set of tools to be developed that
  501.    can facilitate the design of aggregation policy. A query tool to
  502.    allow lookup of aggregation information for a given network or
  503.  
  504.  
  505.  
  506. Knopper & Richardson                                            [Page 9]
  507.  
  508. RFC 1482              Routing Aggregation Support              July 1993
  509.  
  510.  
  511.    aggregate would be very useful. Additional database functionality
  512.    will also be desired for more powerful queries. It is specifically a
  513.    goal to work with RIPE to make sure that the Merit and RIPE database
  514.    approaches are compatible and allow interworking of tools. An AS
  515.    topology database would be most useful in routing policy
  516.    determination and coordination as well.
  517.  
  518.    In addition to these areas, many other issues require further work in
  519.    order to develop the operational framework necessary for the
  520.    successful use of CIDR on the Internet. It is critical that the
  521.    deployment of CIDR and related tools to preserve address and routing
  522.    table space must not compromise the operational stability of the
  523.    NSFNET and the wider Internet.
  524.  
  525. 6. Security Considerations
  526.  
  527.       Security issues are not discussed in this document.
  528.  
  529. 7. Acknowledgements
  530.  
  531.    The authors would like to acknowledge the following persons, whose
  532.    comments and discussions have helped to shape this document:
  533.  
  534.          Dennis Ferguson, Advanced Network and Services, Inc.
  535.          Jeffrey Honig, Cornell University
  536.          William Manning, Rice University/SESQUINET
  537.          The Merit Internet Engineering and Network Management
  538.          Systems groups.
  539.  
  540. 8. Authors' Addresses
  541.  
  542.    Knopper, Mark A.
  543.    Merit Network, Inc.
  544.    1071 Beal Ave.
  545.    Ann Arbor, MI  48109-2103
  546.  
  547.    e-mail: mak@merit.edu
  548.    phone:  (313) 763-6061
  549.    fax:    (313) 747-3745
  550.  
  551.    Richardson, Steven J.
  552.    Merit Network, Inc.
  553.    1071 Beal Ave.
  554.    Ann Arbor, MI  48109-2103
  555.  
  556.    e-mail: sjr@merit.edu
  557.    phone:  (313) 747-4813
  558.    fax:    (313) 747-3745
  559.  
  560.  
  561.  
  562. Knopper & Richardson                                           [Page 10]
  563.  
  564. RFC 1482              Routing Aggregation Support              July 1993
  565.  
  566.  
  567. 9. References
  568.  
  569.    [1]  Fuller, V., Li, T., Yu, J., and Varadhan, K., "Supernetting: an
  570.         Address Assignment and Aggregation Strategy", RFC1338, Update,
  571.         Work in Progress, June 1992.
  572.  
  573.    [2]  Rekhter, Y., and Li, T., "A Border Gateway Protocol 4", Work In
  574.         Progress, April 1993.
  575.  
  576.    [3]  Topolcic, C., "Notes of BGP-4/CIDR Coordination Meeting of 11
  577.         March 93", Work in Progress, March 1993.
  578.  
  579.    [4]  Villamizer, C., in a document describing rcp_routed.conf options
  580.         and syntax, May, 1993.
  581.  
  582.    [5]  Syntax used in Ford, P., Rekhter, Y., Braun, H-W., "Improving
  583.         the Routing and Addressing of IP", IEEE Network, pp. 10-15, May
  584.         1993.
  585.  
  586.    [6]  Ferguson, D., private correspondence, March, 1993.
  587.  
  588.    [7]  Rekhter, Y., and Li, T., "An Architecture for IP Address
  589.         Allocation with CIDR", Work in Progress, February, 1993.
  590.  
  591.    [8]  Gerich, E., "Guidelines for Management of IP Address Space",
  592.         RFC1466, May 1993.
  593.  
  594.    [9]  Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P., and
  595.         Terpstra, M., "Representation of IP Routing Policies in the RIPE
  596.         Database" (ripe-81), Work in Progress, February, 1993.
  597.  
  598.    [10] Rekhter, Y., and Topolcic, C., "Exchanging Routing Information
  599.         Across Provider/Subscriber Boundaries in the CIDR Environment",
  600.         Work in Progress, April 1993.
  601.  
  602.    [11] Fedor, M., Honig, J., Coltun, R., Ferguson, D., "gated-
  603.         config(5)" manpage, from the "gated-R3_0Beta_2" distribution, 7
  604.         October 1992.
  605.  
  606.    [12] Johnson, D., analysis available via anonymous FTP from
  607.         merit.edu:/pub/nsfnet/cidr/auto-aggregates, June 1993.
  608.  
  609.    [13] Topolcic, C., "Schedule for IP Address Space Management
  610.         Guidelines", RFC1367, October, 1993.
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Knopper & Richardson                                           [Page 11]
  619.  
  620.