rfc1482.txt

RFC 的详细文档！

   aggregate downstream to its neighbors.  For example, the CIDR
   aggregate <199.29.128 16> could be listed as:

          CIDR aggregate  home ann  neighbor
          (prefix-length) AS   AS   AS list         contacts
         -----------------------------------------------------------
         <199.29.128 16>  100  100  200 201 690     [e-mail]
         <199.29.128 16>  100  690  266 267 1225... <contact info>
         <199.29.128 16>  100  200  297 372         <contact info>
         <199.29.128 16>  100  201  771 1262        <contact info>

         Note: This can be represented using the syntax used for objects
         in the RIPE-81 paper[9].

   Here, AS 100 (the source AS) performs any aggregation and announces
   the CIDR aggregate <199.29.128 16> to neighbor ASs 200, 201, and 690.
   In turn, AS 200 announces this same aggregate to its neighbor ASs 297
   and 372; further lines show announcements of the given aggregate by
   AS 690 and AS 201.

   Note that this registry reflects both the simple list of aggregates
   that are supported by the union of network providers, as well as
   information on inter-domain topology for the Internet.  Merit will
   implement procedures for registering any network provider's



Knopper & Richardson                                            [Page 6]

RFC 1482              Routing Aggregation Support              July 1993


   aggregates in the Registry; for those CIDR aggregates carried over
   the NSFNET backbone, Merit will implement procedures for integrating
   this Registry with the process of updating the aggregate routing
   announcements.  Requests to update the information will be handled
   via e-mail or on-line registration tools.

4. Effects of CIDR on Operational Aspects of the Internet

   The introduction of CIDR will clearly necessitate various changes
   beyond the introduction of new router software.  In particular, Merit
   and other network service providers will have to adjust tools,
   reports, and procedures as CIDR is implemented and evolved, and these
   changes will have to be coordinated in order to ensure a smooth
   transition to the CIDR-capable Internet.

   While this document is by no means exhaustive, some of the areas
   affected are discussed briefly below; what is intended is to foster
   an awareness of some these changes, so as to initiate thinking about
   and planning for this transition.  While it is obvious that CIDR and
   policy routing imply greater coordination of many operational
   matters, it is not clear how profoundly this will affect the day-to-
   day running of the Internet.

   (Note:  Aspects of the actual phased deployement of CIDR are covered
   in [3] and [10].)

4.1 NSFNET Configuration Files and Reports; Neighbor AS Configurations

   The addition of CIDR capability to the NSFNET Policy-Based Routing
   Database, as outlined in sec. 2, will require the updating of at
   least the following reports which are currently produced by Merit
   (and available via anonymous FTP from nic.merit.edu):

         ans_core.now  as-site.now  country.now net-comp.now  net-net.now
         net-ter.now   non-us.now

   Any tools which access this information, such as the various clients
   or scripts released by Merit or developed by others, will have to be
   changed.

   However, the most striking change will be in the transition from
   rcp_routed to GateD; it is very different in important particulars,
   and follows different conceptual principles [11].

   Network providers which develop any part of their configuration files
   from parsing the NSFNET configuration files or reports *MUST* plan
   for these changes in order to help themselves and the Internet
   community achieve a smooth transition to CIDR.



Knopper & Richardson                                            [Page 7]

RFC 1482              Routing Aggregation Support              July 1993


4.2 Routing and Administrative Policies

   In this document, Merit has stated its commitment to supporting CIDR
   through both changing policies related to administering the NSFNET
   and developing a CIDR Aggregate Registry for the broader Internet
   community.

   In addition to these changes, here are some of the other policies,
   administrative and routing, which must to be coodinated in order to
   achieve optimum benefits of CIDR:

      - policies of the InterNIC and of network service providers in
        assigning (CIDR) IP nets and blocks, as mentioned above;

      - policies of the various ASs in coordination of transit and other
        routing policies;

      - policies of registration of new networks, from the InterNIC or
        network provider, through the CIDR Aggregate Registry, etc.;

      - policies related to coordination of routing changes;

      - coordination of routing policies, in general, to avoid new
        classes of routing problems due to new methods of routing.

4.3 Realtime Issues

   Issues which have not been examined in detail are:

      - debugging of routing/connectivity problems;

      - stability and other properties of routing under various
        scenarios of CIDR configuration and network topology;

      - explicit specification of routing decision algorithms to avoid
        routing anomalies;

      - increased network load due to packets traversing an AS, such as
        the NSFNET backbone, before being discarded due to addressing a
        "hole" in a CIDR aggregate.

4.4 Estimate of Reductions in Routing Tables

   An argument in favor of the implementation CIDR is the effect which
   it should have upon the NSFNET and other routing tables [1] [5].  The
   burning question is: What is the magnitude of this effect?  In view
   of the various issues to be dealt with, this is an important
   consideration.



Knopper & Richardson                                            [Page 8]

RFC 1482              Routing Aggregation Support              July 1993


   In terms of the immediate savings in reduction of the NSFNET backbone
   routing tables, if a set of aggregates were done all at once, a
   recent calculation--which might be characterized as an optimistic
   estimate using a pessimistic algorithm (it looks for the longest
   continuous block of addresses announced to the NSFNET backbone)--
   yields [12]:

        861 size  2 saving  861 announcements
        286 size  4 saving  858 announcements
        117 size  8 saving  819 announcements
         67 size 16 saving 1005 announcements
         13 size 32 saving  403 announcements
          3 size 64 saving  189 announcements
       1347 total   saving 4135 announcements of 12348 (33%).

   Here, the first column represents the number of CIDR aggregates of
   the given "size," and shows the corresponding reduction in net
   announcements due to the adoption of this aggregate.  (A CIDR
   aggregate of "size <n>" is one which encompasses <n> class A, B, or C
   networks; the 67 "size 16" CIDR aggregates actually combine
   announcements for 16 separate networks into a single net aggregate.)
   It is unclear, at this time, whether or not the true savings would be
   of this magnitude, but the extended report provides a basis for
   discussion [12].

   The other aspect of impact upon the routing tables, the reduction in
   the rate of growth (and the concomitant slowing of the rate of
   exhaustion of IP address space), is an entirely different matter.
   Simple calculations related to the rate of class B address space
   exhaustion indicate that CIDR-conformant policies of the InterNIC
   with respect to address assignment is helping [1].

   Clearly, more detailed analysis is desirable in order to better
   understand the realistic gains of the CIDR deployment process, both
   initially and in the longer term.

5.  Conclusions and Next Steps

   Implementation of CIDR is underway, but there is still a fair amount
   of planning and discussion that is needed for a successful
   transition.  Merit is proposing specific functions for CIDR
   aggregation that will be supported by the NSFNET, as well as a CIDR
   Aggregate Registry that can serve as the basis for inter-domain
   routing coordination.

   The Aggregate Registry will allow a set of tools to be developed that
   can facilitate the design of aggregation policy. A query tool to
   allow lookup of aggregation information for a given network or



Knopper & Richardson                                            [Page 9]

RFC 1482              Routing Aggregation Support              July 1993


   aggregate would be very useful. Additional database functionality
   will also be desired for more powerful queries. It is specifically a
   goal to work with RIPE to make sure that the Merit and RIPE database
   approaches are compatible and allow interworking of tools. An AS
   topology database would be most useful in routing policy
   determination and coordination as well.

   In addition to these areas, many other issues require further work in
   order to develop the operational framework necessary for the
   successful use of CIDR on the Internet. It is critical that the
   deployment of CIDR and related tools to preserve address and routing
   table space must not compromise the operational stability of the
   NSFNET and the wider Internet.

6. Security Considerations

      Security issues are not discussed in this document.

7. Acknowledgements

   The authors would like to acknowledge the following persons, whose
   comments and discussions have helped to shape this document:

         Dennis Ferguson, Advanced Network and Services, Inc.
         Jeffrey Honig, Cornell University
         William Manning, Rice University/SESQUINET
         The Merit Internet Engineering and Network Management
         Systems groups.

8. Authors' Addresses

   Knopper, Mark A.
   Merit Network, Inc.
   1071 Beal Ave.
   Ann Arbor, MI  48109-2103

   e-mail: [e-mail]
   phone:  [phone]
   fax:    [phone]

   Richardson, Steven J.
   Merit Network, Inc.
   1071 Beal Ave.
   Ann Arbor, MI  48109-2103

   e-mail: [e-mail]
   phone:  [phone]
   fax:    [phone]



Knopper & Richardson                                           [Page 10]

RFC 1482              Routing Aggregation Support              July 1993


9. References

   [1]  Fuller, V., Li, T., Yu, J., and Varadhan, K., "Supernetting: an
        Address Assignment and Aggregation Strategy", RFC1338, Update,
        Work in Progress, June 1992.

   [2]  Rekhter, Y., and Li, T., "A Border Gateway Protocol 4", Work In
        Progress, April 1993.

   [3]  Topolcic, C., "Notes of BGP-4/CIDR Coordination Meeting of 11
        March 93", Work in Progress, March 1993.

   [4]  Villamizer, C., in a document describing rcp_routed.conf options
        and syntax, May, 1993.

   [5]  Syntax used in Ford, P., Rekhter, Y., Braun, H-W., "Improving
        the Routing and Addressing of IP", IEEE Network, pp. 10-15, May
        1993.

   [6]  Ferguson, D., private correspondence, March, 1993.

   [7]  Rekhter, Y., and Li, T., "An Architecture for IP Address
        Allocation with CIDR", Work in Progress, February, 1993.

   [8]  Gerich, E., "Guidelines for Management of IP Address Space",
        RFC1466, May 1993.

   [9]  Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P., and
        Terpstra, M., "Representation of IP Routing Policies in the RIPE
        Database" (ripe-81), Work in Progress, February, 1993.

   [10] Rekhter, Y., and Topolcic, C., "Exchanging Routing Information
        Across Provider/Subscriber Boundaries in the CIDR Environment",
        Work in Progress, April 1993.

   [11] Fedor, M., Honig, J., Coltun, R., Ferguson, D., "gated-
        config(5)" manpage, from the "gated-R3_0Beta_2" distribution, 7
        October 1992.

   [12] Johnson, D., analysis available via anonymous FTP from
        merit.edu:/pub/nsfnet/cidr/auto-aggregates, June 1993.

   [13] Topolcic, C., "Schedule for IP Address Space Management
        Guidelines", RFC1367, October, 1993.







Knopper & Richardson                                           [Page 11]