Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/internet-drafts/draft-rekhter-cidr-environment-00.txt

Text File | 1993-04-16 | 19.6 KB | 559 lines

                                  - 1 -



Network Working Group                                      Y. Rekhter
INTERNET DRAFT                 T.J. Watson Research Center, IBM Corp.
                                                          C. Topolcic
                                                                 CNRI
                                                           April 1993



 Exchanging Routing Information Across Provider/Subscriber Boundaries
                        in the CIDR Environment


Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   Please check the 1id-abstracts.txt listing contained in the
   internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
   nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
   current status of any Internet Draft.


1   Introduction


   Classless Inter-Domain Routing (CIDR) has been adopted as a solution
   to the scaling problem in the Internet. The overall CIDR architecture
   is described in [1]. The architecture for IP address assignment with
   CIDR is covered in [2] and [3]. The inter-domain routing protocols
   that are capable of supporting CIDR are covered in [4], [5], and [6].

   The purpose of this document is twofold. First, it describes various
   alternatives of exchanging inter-domain routing information across
   domain boundaries, where one of the peering domain is CIDR-capable
   and another is not.  Second, it addresses the implications of running
   CIDR-capable inter-domain routing protocols (e.g. BGP-4, IDRP) on
   intra-domain routing.

   This document is not intended to cover all the cases (either real or
   imaginable). Rather, it focuses on what is viewed to be the most
   common cases.  We expect that individual service
   providers/subscribers will use this document as guidelines in





Expiration Date October 1993                                    [Page 1]

                           - 2 -



   establishing specific operational plans that would deal with
   transition to CIDR.

   Throughout the document we use the concepts of "network service
   provider" and "network service subscriber". These concepts were
   introduced in [3]. For the sake of brevity we'll use terms "service
   provider" and "service subscriber", rather than "network service
   provider" or "network service subscriber".

   This document defines a CIDR-capable provider/subscriber as the
   provider/subscriber that can perform correct IP packet forwarding
   (both internally and to other adjacent providers/subscribers) when
   the inter-domain routing information acquired by the
   provider/subscriber is expressed solely in terms of IP address
   prefixes (with no distinction between A/B/C class of addresses).

   This document defines CIDR-capable forwarding as the ability of a
   router to maintain its forwarding table and to perform correct
   forwarding of IP packets without making any assumptions about the
   class of IP addresses.

   This document defines CIDR reachability information as reachability
   information that may violate any assumptions about the class of IP
   addresses. For instance, a contiguous block of class C networks
   expressed as a single IP address prefix constitutes CIDR reachability
   information.


2   Taxonomy of Service Providers and Service Subscribers


   For the purpose of this document we partition all service providers
   and service subscribers into the following categories, based on the
   type and volume of inter-domain routing information a
   provider/subscriber needs to acquire in order to meet its service
   requirements:


      - Requirements imposed on a service provider/subscriber preclude
        it from using Default inter-domain route(s) -- we'll refer to
        such a provider/subscriber as a Type 1 provider/subscriber.

      - Requirements imposed on a service provider/subscriber allow it
        to rely on using one or more Default routes for inter-domain
        routing, but this information must be supplemented by requiring
        the provider/subscriber to acquire a large percentage of total
        Internet routing information -- we'll refer to such a
        provider/subscriber as a Type 2 provider/subscriber.

      - Requirements imposed on a service provider/subscriber allow it
        to rely on using one or more Default routes for inter-domain





Expiration Date October 1993                                    [Page 2]

                           - 3 -



        routing; however, to meet its service requirements the
        provider/subscriber must supplement Default route(s) by
        acquiring a small percentage of total Internet routing
        information -- we'll refer to such a provider/subscriber as a
        Type 3 provider/subscriber.

      - Requirements imposed on a service subscriber allow it to rely
        solely on using one or more Default routes for inter-domain
        routing; no other inter-domain routing information need to be
        acquired -- we'll refer to such a subscriber as a Type 4
        subscriber.


3   Assumptions on Deployment of CIDR in the Internet


   The document assumes that the CIDR deployment in the Internet will
   proceed as a multi-phase process.

   In the first phase all the major service providers will become CIDR-
   capable. Specifically, all the providers that can't rely on using
   Default route(s) for inter-domain routing (Type 1 providers) are
   expected to deploy BGP-4 and transition to CIDR during this phase. It
   is expected that CIDR reachability information will first appear in
   the Internet upon transition of all Type 1 service
   providers/subscribers to CIDR.

   The second phase will commence upon completion of the first phase.
   During the second phase other service providers/subscribers that are
   connected to the service providers that were transitioned to CIDR
   during the first phase will become CIDR-capable.  Specifically,
   during the second phase it is expected that most of the
   providers/subscribers that need to acquire a large percentage of the
   total Internet routing information (Type 2 provider/subscriber) will
   become CIDR-capable.  In addition, during the second phase some of
   the Type 3 providers/subscribers may become CIDR-capable as well.
   This plan was agreed to by a number of major providers [8]. NSFNET's
   steps to implement this plan are described in [9].

   Finally, during the third phase the rest of the Type 3
   providers/subscribers and most of the Type 4 subscribers will
   transition to CIDR.

   It is expected that duration of the first phase will be significantly
   shorter than duration of the second phase.  Likewise, duration of the
   second phase is expected to be shorter than duration of the third
   phase.









Expiration Date October 1993                                    [Page 3]

                           - 4 -



4   Implications of CIDR on Interior Routing


   A CIDR-capable service provider/subscriber can use the following two
   techniques to distribute exterior routing information to all of its
   routers (both interior and border):


      - utilize internal BGP/IDRP between all the routers

      - use CIDR-capable IGPs (e.g. OSPF, IS-IS, RIP2)

   The first technique doesn't impose any addition requirements on the
   IGP within the provider/subscriber. Additional information on
   implementing the first option is presented in [5] (see Section
   A.2.4).

   The second technique allows the provider/subscriber to reduce the
   utilization of internal BGP/IDRP, but imposes specific requirements
   on the intra-domain routing. It also requires the ability to inject
   inter-domain routing information (acquired either via BGP or IDRP)
   into the intra-domain routing. Additional details on implementing the
   second option are provided in [7]. It is not expected that all the
   features enumerated in [7] will be widely needed. Therefore, it would
   be highly desirable to prioritize the features.

   Note that both of these techniques imply that all the routers within
   a CIDR-capable service provider/subscriber need to be capable of
   CIDR-based forwarding.

   Discussion of which of the two techniques should be preferred is
   outside the scope of this document.


5   Exchanging Inter-Domain Routing Information


   At each phase during the transition to CIDR one of the essential
   aspects of the Internet operations will be the exchange of inter-
   domain routing information between CIDR-capable providers/subscribers
   and CIDR-incapable provider/subscribers.

   When exchanging inter-domain routing information between a CIDR-
   capable provider/subscriber and a CIDR-incapable provider/subscriber,
   it is of utmost importance to take into account the view each side
   wants of the other to present. This view has two distinct aspects:


      - the type of routing information exchanged (e.g. Default route,
        traditional (non-CIDR) reachability information, CIDR
        reachability information)





Expiration Date October 1993                                    [Page 4]

                           - 5 -



      - routing information processing each side needs to do to maintain
        these views (e.g. ability to perform aggregation, ability to
        perform controlled de-aggregation)

   The exchange of inter-domain routing information is expected to be
   controlled by bilateral agreements between the directly connected
   service providers/subscribers. Consequently, the views each side
   wants of the other are expected to form an essential component of
   such agreements.

   To facilitate troubleshooting and problem isolation, the bilateral
   agreements should be made accessible to other providers/subscribers.
   One way to accomplish this is by placing them in a generally
   accessible database. The details of how this can be implemented are
   outside the scope of this document. A possible way to accomplish this
   is described in [9].

   Since the exchange of inter-domain routing information across
   provider/subscriber boundaries occurs on a per peer basis, a border
   router is expected to provide necessary mechanisms (e.g.
   configuration) that will control exchange and processing of this
   information on a per peer basis.

   In the following sections we describe possible scenarios for
   exchanging inter-domain routing information. It is always assumed
   that one side is CIDR-capable and the other is not.


5.1 Exchanging Inter-Domain Routing Information between CIDR-capable
    providers and CIDR-incapable Type 2 (default with large proportion of
    explicit routes) providers/subscribers


   When a CIDR-capable provider receives inter-domain routing
   information from a CIDR-incapable Type 2 provider/subscriber, it is
   expected that the border router(s) within the CIDR-capable provider
   will be capable of performing aggregation of this information. 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/subscriber) requests. In other words, the aggregation shall
   only be done on agreement by the recipient (the CIDR-capable
   provider).

   Passing inter-domain routing information from a CIDR-capable provider
   to a CIDR-incapable Type 2 provider/subscriber 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/subscriber





Expiration Date October 1993                                    [Page 5]

                           - 6 -



      - 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 the third item. 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
   (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/subscriber 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/subscribers 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 when dealing with Type 2
   providers/subscribers could be addressed by a combination of
   exchanging specific non-CIDR reachability information and an inter-
   domain Default route. Any inconvenience to a provider/subscriber due
   to the use of an inter-domain Default route will be removed once the
   provider/subscriber 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 to point out that
   due to the nature of Type 2 provider/subscriber (it needs to acquire
   a large percentage of total inter-domain routing information) it is
   expected that the controlled de-aggregation would result in a non-
   negligible 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/subscribers







Expiration Date October 1993                                    [Page 6]

                           - 7 -



   The only difference between this case and the case described in
   Section 5.1 is the fact that a CIDR-incapable provider/subscriber
   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/subscriber 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 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/subscriber. 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/subscriber) requests.

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


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

   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/subscriber. 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/subscriber) requests.


6  Conclusions


   It is expected that the reduction in the global volume of routing
   information will begin immediately upon completion of the first
   phase. The second phase will allow to simplify bilateral arrangements
   between connected service providers/subscribers by shifting the
   responsibility for routing information aggregation towards the
   parties that are better suitable for this, 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.






Expiration Date October 1993                                    [Page 7]

                           - 8 -



7   Security Considerations


   Security issues are not discussed in this document.


8   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).


9   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
   Reston, VA 22091
   Phone: [phone]
   EMail: [e-mail]


10  References


   [1] Fuller, V., Li, T., Yu, J., and Varadhan, K., `Supernetting: an
   Address Assignment and Aggregation Strategy', RFC1338, June 1992

   [2] Gerich, E., `Guidelines for Management of IP Address Space',
   RFC1366, October 1992

   [3] Rekhter, Y., Li, T., `An Architecture for IP Address Allocation
   with CIDR', Internet Draft, January 1993

   [4] Rekhter, Y., Li, T., `A Border Gateway Protocol 4 (BGP-4)',
   Internet Draft, December 1992





Expiration Date October 1993                                    [Page 8]

                           - 9 -



   [5] Rekhter, Y., Gross, P., `Application of the Border Gateway
   Protocol in the Internet', Internet Draft, September 1992

   [6] Hares, S., `IDRP for IP', Internet Draft, June 1992

   [7] Varadhan, K., `BGP4 OSPF Interaction', Internet Draft, September
   1992

   [8] Topolcic, C., `Notes on BGP-4/CIDR Coordination Meeting of 11
   March 93', Internet Draft, March 1993

   [9] Knopper, M., `Aggregation Support in the NSFNET Policy Routing
   Database', Internet Draft, March 1993











































Expiration Date October 1993                                    [Page 9]