rfc1745.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                       K.  Varadhan
Request for Comments: 1745                                  OARnet & ISI
Category: Standards Track                                       S. Hares
                                                            NSFnet/Merit
                                                              Y. Rekhter
                                  T.J. Watson Research Center, IBM Corp.
                                                           December 1994


                  BGP4/IDRP for IP---OSPF Interaction

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This memo defines the various criteria to be used when designing an
   Autonomous System Border Router (ASBR) that will run either BGP4 or
   IDRP for IP with other ASBRs external to the AS and OSPF as its IGP.

Table of Contents

   1.  Introduction .................................................  2
   2.  Reachability Information Exchange ............................  4
   2.1.  Exporting OSPF information into BGP/IDRP  ..................  4
   2.2.  Importing BGP/IDRP information into OSPF ...................  6
   3.  BGP/IDRP Identifier and OSPF router ID .......................  7
   4.  Setting OSPF tags, ORIGIN and PATH attributes ................  8
   4.1.  Configuration parameters for setting the OSPF tag .......... 10
   4.2.  Manually configured tags ................................... 10
   4.3.  Automatically generated tags ............................... 11
   4.3.1. Tag = <Automatic = 1, Complete = 0, PathLength = 00> ...... 11
   4.3.2. Tag = <Automatic = 1, Complete = 0, PathLength = 01> ...... 11
   4.3.3. Tag = <Automatic = 1, Complete = 0, PathLength = 10> ...... 12
   4.3.4. Tag = <Automatic = 1, Complete = 1, PathLength = 00> ...... 12
   4.3.5. Tag = <Automatic = 1, Complete = 1, PathLength = 01> ...... 12
   4.3.6. Tag = <Automatic = 1, Complete = 1, PathLength = 10> ...... 13
   4.4.  Miscellaneous tag settings ................................. 14
   5.  Setting OSPF Forwarding Address and BGP NEXT_HOP attribute ... 14
   6.  Changes from the BGP 3 - OSPF interactions document .......... 15
   7.  Security Considerations ...................................... 16
   8.  Acknowledgements ............................................. 16
   9.  Bibliography ................................................. 16



Varadhan, Hares & Rekhter                                       [Page 1]

RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994


   10.  Appendix .................................................... 18
   11.  Authors' Present Addresses .................................. 19

1.  Introduction

   This document defines the various criteria to be used when designing
   an Autonomous System Border Router (ASBR) that will run BGP4
   [RFC1654] or IDRP for IP [IDRP] with other ASBRs external to the AS,
   and OSPF [RFC1583] as its IGP.

   All future references of BGP in this document will refer to BGP
   version 4, as defined in [RFC1654].  All reference to IDRP are
   references to the Inter-Domain Routing Protocol (ISO 10747) which has
   been defined by the IDRP for IP document [IDRP] for use in Autonomous
   Systems.

   This document defines how the following fields in OSPF and attributes
   in BGP/IDRP are to be set when interfacing between BGP/IDRP and OSPF
   at an ASBR:

   IDRP came out of the same work as BGP, and may be consider a follow
   on to BGP-3 and BGP-4.  Most fields defined in the interaction
   between BGP and IDRP are named the same.  Where different, the IDRP
   fields are shown separately.

           BGP/IDRP MULTI_EXIT_DISC

           BGP ORIGIN and AS_PATH/AS_SET     vs. OSPF tag
           IDRP EXT_INFO and RD_PATH/RD_SET

           BGP/IDRP NEXT_HOP                 vs. OSPF Forwarding Address

           BGP/IDRP LOCAL_PREF               vs. OSPF cost and type

   IDRP contains RD_PATH and RD_SET fields which serves the same purpose
   as AS_PATH and AS_SET fields for IDRP for IP.  In this document, we
   will use the terms PATH and SET to refer to the BGP AS_PATH and
   AS_SET, or the IDRP RD_PATH and RD_SET fields respectively, depending
   on the context of the protocol being used.

   Both IDRP and BGP provide a mechanism to indicate whether the routing
   information was originated via an IGP, or some other means.  In IDRP,
   if route information is originated by means other than an IGP, then
   the EXT_INFO attribute is present.  Likewise, in BGP, if a route
   information is originated by means other than an IGP, then the ORIGIN
   attribute is set to <EGP> or <INCOMPLETE>.  For the purpose of this
   document, we need to distinguish between the two cases:




Varadhan, Hares & Rekhter                                       [Page 2]

RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994


        (a)  Route information was originated via an IGP,

        (b)  Route information was originated by some other means.

   The former case is realized in IDRP by not including the EXT_INFO
   attribute, and in BGP by setting the BGP ORIGIN=<IGP>;  The latter
   case is realized by including the EXT_INFO attribute in IDRP, and by
   setting the BGP ORIGIN=<EGP>.  For the rest of the document, we will
   use the BGP ORIGIN=<IGP> to refer to the former scenario, and BGP
   ORIGIN=<EGP> to refer to the latter.

   One other difference between IDRP and BGP remains.  IDRP for IP
   identifies an autonomous system by an identifier of variable length
   that is syntactically identical to an NSAP address prefix, and
   explicitly embeds the autonomous system number [IDRP].  BGP
   identifies an autonomous system just by an autonomous system number.
   Since there is a one-to-one mapping between how an autonomous system
   is identified in IDRP and in BGP, in this document, we shall identify
   an autonomous system by its autonomous system number.

   For a more general treatise on routing and route exchange problems,
   please refer to [ROUTE-LEAKING] and [NEXT-HOP] by Philip Almquist.

   This document uses the two terms "Autonomous System" and "Routing
   Domain".  The definitions for the two are below:

   The term Autonomous System is the same as is used in the BGP RFC
   [RFC1267], given below:

      "The use of the term Autonomous System here stresses the fact
      that, even when multiple IGPs and metrics are used, the
      administration of an AS appears to other ASs to have a single
      coherent interior routing plan and presents a consistent picture
      of what destinations are reachable through it.  From the
      standpoint of exterior routing, an AS can be viewed as monolithic:
      reachability to destinations directly connected to the AS must be
      equivalent from all border gateways of the AS."

   The term Routing Domain was first used in [ROUTE-LEAKING] and is
   given below:

      "A Routing Domain is a collection of routers which coordinate
      their routing knowledge using a single [instance of a] routing
      protocol."

   By definition, a Routing Domain forms a single Autonomous System, but
   an Autonomous System may be composed of a collection of Routing
   Domains.



Varadhan, Hares & Rekhter                                       [Page 3]

RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994


   BGP, IDRP and OSPF have the concept of a set of reachable
   destinations.  This set is called NLRI or Network Layer Reachability
   Information.  The set can be represented either as an IP address
   prefix, or an address, mask pair.  Note that if the mask is
   contiguous in the latter, then the two representations are
   equivalent.  In this document, we use the term "address/mask pair" in
   the context of OSPF, and "destination" or "set of reachable
   destinations" in the context of BGP or IDRP.

   This document follows the conventions embodied in the Host
   Requirements RFCs [RFC1122, RFC1123], when using the terms "MUST",
   "SHOULD," and "MAY" for the various requirements.

   A minimal implementation of BGP/IDRP OSPF exchange MUST not advertise
   a route containing a set of reachable destinations when none of the
   destinations in the address/mask pair is reachable via OSPF (section
   2.1, bullet 3), MUST merge the PATH into a SET when multiple exit
   points exist within the same autonomous system for the same external
   destination (section 3), MUST set the OSPF tag accurately (section
   4).  This subset is chosen so as to cause minimal havoc to the
   Internet at large.  It is strongly recommended that implementors
   implement more than a minimalistic specification.

2.  Reachability Information Exchange

   This section discusses the constraints that must be met to exchange
   the set of reachable destinations between an external BGP/IDRP peer
   from another AS and internal OSPF address/mask pairs.

   2.1.  Exporting OSPF information into BGP

      1.   The administrator MUST be able to selectively export
           address/mask pairs into BGP/IDRP via an appropriate filter
           mechanism.

           This filter mechanism MUST support such control with the
           granularity of an address/mask pair.

           This filter mechanism will be the primary method of
           aggregation of OSPF internal and type 1 and type 2 external
           routes within the AS into BGP/IDRP.

           Additionally, the administrator MUST be able to filter based
           on the OSPF tag and the various sub-fields of the OSPF tag.
           The settings of the tag and the sub-fields are defined in
           section 4 in more detail.





Varadhan, Hares & Rekhter                                       [Page 4]

RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994


           o    The default MUST be to export no routes from OSPF into
                BGP/IDRP.  A single configuration parameter MUST permit
                all OSPF inter-area and intra-area address/mask pairs to
                be exported into BGP/IDRP.

                OSPF external address/mask pairs of type 1 and type 2
                MUST never be exported into BGP/IDRP unless they are
                explicitly configured.

      2.   An address/mask pair having a non-contiguous mask MUST not be
           exported to BGP/IDRP.

      3.   When configured to export an address/mask pair from OSPF into
           BGP/IDRP, the ASBR MAY advertise the route containing the set
           of reachable destinations via BGP/IDRP as soon as at least
           one of the destinations in the address/mask pair is
           determined to be reachable via OSPF; it MUST stop advertising
           the route containing the set of reachable destinations when
           none of the destinations in the address/mask pair is
           reachable via OSPF.

      4.   The network administrator MUST be able to statically
           configure the BGP/IDRP attribute MULTI_EXIT_DISC attribute to
           be used for any route.

           o    The default MUST be to omit the MULTI_EXIT_DISC in the
                route advertised via BGP/IDRP.

      5.   An implementation of BGP/IDRP and OSPF on an ASBR MUST have a
           mechanism to set up a minimum amount of time that must elapse
           between the learning of a new address/mask pair via OSPF and
           subsequent advertisement of the address/mask pair via
           BGP/IDRP to the external neighbours.

           o    The default value for this setting MUST be 0, indicating
                that the address/mask pair is to be advertised to the
                neighbour BGP/IDRP peers instantly.

                Note that BGP and IDRP mandate a mechanism to dampen the
                inbound advertisements from adjacent neighbours.  See
                the variable MinRouteAdvertisementInterval in section
                9.2.3.1, [RFC1654] or in section 7.17.3.1, [IS10747].

      6.   LOCAL_PREF is not used when exporting OSPF information into
           BGP/IDRP, as it is not applicable.






Varadhan, Hares & Rekhter                                       [Page 5]

RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994


   2.2.  Importing BGP/IDRP information into OSPF

      1.   BGP/IDRP implementations SHOULD allow an AS to control
           announcements of BGP/IDRP learned set of reachable
           destinations into OSPF.  Implementations SHOULD support such
           control with the granularity of a single destination.

           Implementations SHOULD also support such control with the
           granularity of an autonomous system, where the autonomous
           system may be either the autonomous system that originated
           the information or the autonomous system that advertised the
           information to the local system (adjacent autonomous system).

           o    The default MUST be to import nothing from BGP/IDRP into
                OSPF.  Administrators must configure every destination
                they wish to import.

                A configuration parameter MAY allow an administrator to
                configure an ASBR to import all the set of reachable
                destinations from BGP/IDRP into the OSPF routing domain.

      2.   The administrator MUST be able to configure the OSPF cost and
           the OSPF metric type of every destination imported into OSPF.
           The OSPF metric type MUST default to type 2. If the
           LOCAL_PREF value is used to construct the OSPF cost, one must
           be extremely careful with such a conversion. In OSPF the
           lower cost is preferred, while in BGP/IDRP the higher value
           of the LOCAL_PREF is preferred.  In addition, the OSPF cost
           ranges between 1 and 2^24, while the LOCAL_PREF value ranges
           between 0 and 2^32.  Note that if ASBRs within a domain are
           configured to correlate BGP/IDRP and OSPF information (as
           described in Section 3), then the route selection by the
           ASBRs is determined solely by the OSPF cost, and the value
           carried by the LOCAL_PREF attribute has no impact on the
           route selection.

      3.   Information learned via BGP/IDRP from peers within the same
           AS MUST not be imported into OSPF.

      4.   The ASBR MUST never generate a default destination into the
           OSPF routing domain unless explicitly configured to do so.

           A default destination is a set of all possible destinations.
           By convention, it is represented as a prefix of 0 length or a
           mask of all zeroes.

           A possible criterion for generating default into an IGP is to
           allow the administrator to specify a set of (set of reachable



Varadhan, Hares & Rekhter                                       [Page 6]

RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994


           destinations, PATH, default cost, default type) tuples.  If
           the ASBR learns of at least one of the destinations in the
           set of reachable destinations, with the corresponding PATH,
           then it generates a default destination into the OSPF routing
           domain, with the appropriate cost and type.  The lowest cost
           route will then be injected into the OSPF routing domain.

           This is the recommended method for originating default
           destinations in the OSPF routing domain.

      5.   Note that [RFC1247] requires the network number to be used as
           the Link State ID.  This will produce a conflict if the ASBR
           tries to import two destinations, differing only in their
           prefix length.  This problem is fixed in [RFC1583], which