rfc1520.txt

RFC 的详细文档！

   requests. In other words, the aggregation shall be done by the CIDR-
   capable provider (the receiver) and only when agreed to by the CIDR-
   incapable provider (the sender).

   Passing inter-domain routing information from a CIDR-capable provider
   to a CIDR-incapable Type 2 provider will require an agreement between
   the two that would cover the following items:

      - under what conditions the CIDR-capable provider can pass an
        inter-domain Default route to the CIDR-incapable provider

      - exchange of specific non-CIDR reachability information

      - controlled de-aggregation of CIDR reachability information

   Agreements that cover the first two items are already implemented
   within the Internet. Thus, the only additional factor introduced by
   CIDR is controlled de-aggregation. A CIDR-capable provider may decide
   not to de-aggregate any CIDR reachability information, or to de-
   aggregate some or all of the CIDR reachability information.

   If a CIDR-capable provider does not de-aggregate CIDR reachability
   information, then its non-CIDR Type 2 peer can obtain reachability
   information from it either as non-CIDR reachability information



Rekhter & Topolcic                                              [Page 5]

RFC 1520           CIDR Provider Information Exchange     September 1993


   (explicit Class A/B/C network advertisement) or as an inter-domain
   Default route.  Since most of the current reachability information in
   the Internet is non-CIDR, a Type 2 provider would be able to acquire
   this information as explicit Class A/B/C network advertisements from
   the CIDR-capable provider, as it does now.  Further, it is expected
   that at least on a temporary basis (until the completion of the
   second phase of the transition) in a majority of cases, Type 2
   providers should be able to use an inter-domain Default route
   (acquired from the CIDR-capable provider) as a way of dealing with
   forwarding to destinations covered by CIDR reachability information.

   Thus, it is expected that most of the cases involving a CIDR-capable
   Type 2 provider and a CIDR-capable provider that does not perform
   de-aggregation could be addressed by a combination of exchanging
   specific non-CIDR reachability information and an inter-domain
   Default route. Any inconvenience to a CIDR-incapable provider due to
   the use of an inter-domain Default route will be removed once the
   provider transitions to CIDR.

   On the other hand, a CIDR-capable provider may decide to perform
   controlled de-aggregation of CIDR reachability information.
   Additional information on performing controlled de-aggregation can be
   found in [5] (Section 8).  Special care must be taken when de-
   aggregating CIDR reachability information carried by a route with the
   ATOMIC_AGGREGATE path attribute.  It is worth while pointing out that
   due to the nature of Type 2 provider (it needs to acquire a large
   percentage of total inter-domain routing information) it is expected
   that the controlled de-aggregation would result in substantial
   configuration at the border router that performs the de-aggregation.

5.2  Exchanging Inter-Domain Routing Information between CIDR-capable
     providers and CIDR-incapable Type 3 (Default with few explicit
     routes) providers

   In this case, as in the case described in Section 5.1, it is expected
   that a border router in a CIDR-capable provider would be able to
   aggregate routing information it receives from a CIDR-incapable Type
   3 provider. The aggregation is expected to be governed and controlled
   via a bilateral agreement.  Specifically, the CIDR capable provider
   is expected to aggregate only the information the CIDR-incapable
   provider requests.

   The only difference between this case and the case described in
   Section 5.1 is the fact that a CIDR-incapable provider requires just
   a small percentage of total inter-domain routing information. If this
   information falls into a non-CIDR category, then a Type 3 provider
   would be able to acquire it from a CIDR-capable provider. If this is
   CIDR reachability information, then in a majority of cases it is



Rekhter & Topolcic                                              [Page 6]

RFC 1520           CIDR Provider Information Exchange     September 1993


   expected that forwarding to destinations covered by this information
   could be handled via an inter-domain Default route.

   It is still expected that a border router in a CIDR-capable provider
   would be able to aggregate routing information it receives from a
   CIDR-incapable Type 3 provider. The aggregation is expected to be
   governed and controlled via a bilateral agreement.  Specifically, the
   CIDR capable provider is expected to aggregate only the information
   the other side (the CIDR-incapable provider) requests.

5.3  Exchanging Inter-Domain Routing Information between CIDR-capable
     providers and CIDR-incapable Type 4 (Default only) providers

   Again, it is still expected that a border router in a CIDR-capable
   provider would be able to aggregate routing information it receives
   from a CIDR-incapable Type 4 provider. The aggregation is expected to
   be governed and controlled via a bilateral agreement.  Specifically,
   the CIDR capable provider is expected to aggregate only the
   information the CIDR-incapable provider requests.

   The only difference between this case and the case described in
   Section 5.1 is the fact that CIDR-incapable provider would not
   require any inter-domain routing information, other than the Default
   inter-domain route. Therefore, controlled de-aggregation of CIDR
   reachability information is not an issue.

6. Conclusions

   It is expected that the reduction in the global volume of routing
   information will begin immediately upon completion of the first phase
   of the transition to CIDR. The second phase will allow simpler
   bilateral arrangements between connected service providers by
   shifting the responsibility for routing information aggregation
   towards the parties that are better suitable for it, and by
   significantly reducing the need for routing information de-
   aggregation. Thus, most of the gain achieved during the second phase
   will come from simplifying bilateral agreements. The third phase it
   intended to complete the goals and objectives of the second phase.

7.  Acknowledgments

   This document was largely stimulated by the discussion that took
   place during the Merit/NSFNET Regional Tech Meeting in Boulder,
   January 21-22, 1993.  We would like specifically acknowledge
   contributions by Peter Ford (Los Alamos National Laboratory), Elise
   Gerich (NSFNET/Merit), Susan Hares (NSFNET/Merit), Mark Knopper
   (NSFNET/Merit), Bill Manning (Sesquinet/Rice University), and John
   Scudder (NSFNET/Merit).



Rekhter & Topolcic                                              [Page 7]

RFC 1520           CIDR Provider Information Exchange     September 1993


8.  References

   [1] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
       Domain Routing (CIDR): An Address Assignment and Aggregation
       Strategy", RFC 1519, BARRNet, cisco, Merit, and OARnet, September
       1993.

   [2] Gerich, E., "Guidelines for Management of IP Address Space", RFC
       1466, Merit, May 1993.

   [3] Rekhter, Y., and T. Li, "An Architecture for IP Address
       Allocation with CIDR", RFC 1518, T.J. Watson Research Center, IBM
       Corp., cisco Systems, September 1993.

   [4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
       Work in Progress, June 1993.

   [5] Rekhter, Y., and P. Gross, "Application of the Border Gateway
       Protocol in the Internet", Work in Progress, September 1992.

   [6] Hares, S., "IDRP for IP", Work in Progress, March 1993.

   [7] Varadhan, K., "BGP4 OSPF Interaction", Work in Progress, March
       1993.

   [8] Topolcic, C., "Notes on BGP-4/CIDR Coordination Meeting of 11
       March 93", Informal Notes, March 1993.

   [9] Knopper, M., "Aggregation Support in the NSFNET Policy Routing
       Database", RFC 1482, Merit, June 1993.

9.  Security Considerations

       Security issues are not discussed in this memo.

















Rekhter & Topolcic                                              [Page 8]

RFC 1520           CIDR Provider Information Exchange     September 1993


10.  Authors' Addresses

       Yakov Rekhter
       T.J. Watson Research Center, IBM Corporation
       P.O. Box 218
       Yorktown Heights, NY 10598

       Phone: [phone]
       EMail: [e-mail]


       Claudio Topolcic
       Corporation for National Research Initiatives
       1895 Preston White Drive, Suite 100
       Suite 100
       Reston, VA 22091

       Phone: [phone]
       EMail: [e-mail]
































Rekhter & Topolcic                                              [Page 9]