rfc1772.txt

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

   form of configuration information.

   BGP enforces policies by affecting the selection of paths from
   multiple alternatives and by controlling the redistribution of
   routing information.  Policies are determined by the AS
   administration.

   Routing policies are related to political, security, or economic
   considerations. For example, if an AS is unwilling to carry traffic
   to another AS, it can enforce a policy prohibiting this. The
   following are examples of routing policies that can be enforced with
   the use of BGP:

     1.  A multihomed AS can refuse to act as a transit AS for other
         AS's.  (It does so by only advertising routes to destinations
         internal to the AS.)

     2.  A multihomed AS can become a transit AS for a restricted set of
         adjacent AS's, i.e., some, but not all, AS's can use the
         multihomed AS as a transit AS. (It does so by advertising its
         routing information to this set of AS's.)

     3.  An AS can favor or disfavor the use of certain AS's for
         carrying transit traffic from itself.

   A number of performance-related criteria can be controlled with the
   use of BGP:

     1.  An AS can minimize the number of transit AS's. (Shorter AS
         paths can be preferred over longer ones.)

     2.  The quality of transit AS's. If an AS determines that two or
         more AS paths can be used to reach a given destination, that AS
         can use a variety of means to decide which of the candidate AS



Rekhter & Gross                                                 [Page 7]

RFC 1772                   BGP-4 Application                  March 1995


         paths it will use. The quality of an AS can be measured by such
         things as diameter, link speed, capacity, tendency to become
         congested, and quality of operation. Information about these
         qualities might be determined by means other than BGP.

     3.  Preference of internal routes over external routes.

   For consistency within an AS, equal cost paths, resulting from
   combinations of policies and/or normal route selection procedures,
   must be resolved in a consistent fashion.

   Fundamental to BGP is the rule that an AS advertises to its
   neighboring AS's only those routes that it uses. This rule reflects
   the "hop-by-hop" routing paradigm generally used by the current
   Internet.

6. Path Selection with BGP

   One of the major tasks of a BGP speaker is to evaluate different
   paths from itself to a set of destination covered by an address
   prefix, select the best one, apply appropriate policy constraints,
   and then advertise it to all of its BGP neighbors. The key issue is
   how different paths are evaluated and compared.  In traditional
   distance vector protocols (e.g., RIP) there is only one metric (e.g.,
   hop count) associated with a path. As such, comparison of different
   paths is reduced to simply comparing two numbers. A complication in
   Inter-AS routing arises from the lack of a universally agreed-upon
   metric among AS's that can be used to evaluate external paths.
   Rather, each AS may have its own set of criteria for path evaluation.

   A BGP speaker builds a routing database consisting of the set of all
   feasible paths and the list of destinations (expressed as address
   prefixes) reachable through each path.  For purposes of precise
   discussion, it's useful to consider the set of feasible paths for a
   set of destinations associated with a given address prefix. In most
   cases, we would expect to find only one feasible path. However, when
   this is not the case, all feasible paths should be maintained, and
   their maintenance speeds adaptation to the loss of the primary path.
   Only the primary path at any given time will ever be advertised.

   The path selection process can be formalized by defining a complete
   order over the set of all feasible paths to a set of destinations
   associated with a given address prefix.  One way to define this
   complete order is to define a function that maps each full AS path to
   a non-negative integer that denotes the path's degree of preference.
   Path selection is then reduced to applying this function to all
   feasible paths and choosing the one with the highest degree of
   preference.



Rekhter & Gross                                                 [Page 8]

RFC 1772                   BGP-4 Application                  March 1995


   In actual BGP implementations, the criteria for assigning degree of
   preferences to a path are specified as configuration information.

   The process of assigning a degree of preference to a path can be
   based on several sources of information:

     1.  Information explicitly present in the full AS path.

     2.  A combination of information that can be derived from the full
         AS path and information outside the scope of BGP (e.g., policy
         routing constraints provided as configuration information).

   Possible criteria for assigning a degree of preference to a path are:

       - AS count. Paths with a smaller AS count are generally better.

       - Policy considerations. BGP supports policy-based routing based
         on the controlled distribution of routing information.  A BGP
         speaker may be aware of some policy constraints (both within
         and outside of its own AS) and do appropriate path selection.
         Paths that do not comply with policy requirements are not
         considered further.

       - Presence or absence of a certain AS or AS's in the path. By
         means of information outside the scope of BGP, an AS may know
         some performance characteristics (e.g., bandwidth, MTU, intra-
         AS diameter) of certain AS's and may try to avoid or prefer
         them.

       - Path origin. A path learned entirely from BGP (i.e., whose
         endpoint is internal to the last AS on the path) is generally
         better than one for which part of the path was learned via EGP
         or some other means.

       - AS path subsets. An AS path that is a subset of a longer AS
         path to the same destination should be preferred over the
         longer path.  Any problem in the shorter path (such as an
         outage) will also be a problem in the longer path.

       - Link dynamics. Stable paths should be preferred over unstable
         ones. Note that this criterion must be used in a very careful
         way to avoid causing unnecessary route fluctuation. Generally,
         any criteria that depend on dynamic information might cause
         routing instability and should be treated very carefully.







Rekhter & Gross                                                 [Page 9]

RFC 1772                   BGP-4 Application                  March 1995


7. Required set of supported routing policies

Policies are provided to BGP in the form of configuration
information.  This information is not directly encoded in the
protocol. Therefore, BGP can provide support for very complex routing
policies. However, it is not required that all BGP implementations
support such policies.

We are not attempting to standardize the routing policies that must
be supported in every BGP implementation; we strongly encourage all
implementors to support the following set of routing policies:

     1.  BGP implementations should allow an AS to control announcements
         of BGP-learned routes to adjacent AS's.  Implementations should
         also support such control with at least the granularity of a
         single address prefix.  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 route, or the autonomous system that
         advertised the route to the local system (adjacent autonomous
         system).  Care must be taken when a BGP speaker selects a new
         route that can't be announced to a particular external peer,
         while the previously selected route was announced to that peer.
         Specifically, the local system must explicitly indicate to the
         peer that the previous route is now infeasible.

     2.  BGP implementations should allow an AS to prefer a particular
         path to a destination (when more than one path is available).
         At the minimum an implementation shall support this
         functionality by allowing to administratively assign a degree
         of preference to a route based solely on the IP address of the
         neighbor the route is received from. The allowed range of the
         assigned degree of preference shall be between 0 and 2^(31) -
         1.

     3.  BGP implementations should allow an AS to ignore routes with
         certain AS's in the AS_PATH path attribute.  Such function can
         be implemented by using the technique outlined in [2], and by
         assigning "infinity" as "weights" for such AS's. The route
         selection process must ignore routes that have "weight" equal
         to "infinity".

8. Interaction with other exterior routing protocols

   The guidelines suggested in this section are consistent with the
   guidelines presented in [3].





Rekhter & Gross                                                [Page 10]

RFC 1772                   BGP-4 Application                  March 1995


   An AS should advertise a minimal aggregate for its internal
   destinations with respect to the amount of address space that it is
   actually using.  This can be used by administrators of non-BGP 4 AS's
   to determine how many routes to explode from a single aggregate.

   A route that carries the ATOMIC_AGGREGATE path attribute shall not be
   exported into either BGP-3 or EGP2, unless such an exportation can be
   accomplished without exploding the NLRI of the route.

8.1 Exchanging information with EGP2

   This document suggests the following guidelines for exchanging
   routing information between BGP-4 and EGP2.

   To provide for graceful migration, a BGP speaker may participate in
   EGP2, as well as in BGP-4. Thus, a BGP speaker may receive IP
   reachability information by means of EGP2 as well as by means of
   BGP-4.  The information received by EGP2 can be injected into BGP-4
   with the ORIGIN path attribute set to 1.  Likewise,  the information
   received via BGP-4 can be injected into EGP2 as well. In the latter
   case, however, one needs to be aware of the potential information
   explosion when a given IP prefix received from BGP-4 denotes a set of
   consecutive A/B/C class networks.  Injection of BGP-4 received NLRI
   that denotes IP subnets requires the BGP speaker to inject the
   corresponding network into EGP2.  The local system shall provide
   mechanisms to control the exchange of reachability information
   between EGP2 and BGP-4.  Specifically, a conformant implementation is
   required to support all of the following options when injecting BGP-4
   received reachability information into EGP2:

       - inject default only (0.0.0.0); no export of any other NLRI

       - allow controlled deaggregation, but only of specific routes;
         allow export of non-aggregated NLRI

       - allow export of only non-aggregated NLRI

   The exchange of routing information via EGP2 between a BGP speaker
   participating in BGP-4 and a pure EGP2 speaker may occur  only at the
   domain (autonomous system) boundaries.

8.2 Exchanging information with BGP-3

   This document suggests the following guidelines for exchanging
   routing information between BGP-4 and BGP-3.

   To provide for graceful migration, a BGP speaker may participate in
   BGP-3, as well as in BGP-4. Thus, a BGP speaker may receive IP



Rekhter & Gross                                                [Page 11]

RFC 1772                   BGP-4 Application                  March 1995


   reachability information by means of BGP-3, as well as by means of
   BGP-4.

   A BGP speaker may inject the information received by BGP-4 into BGP-3
   as follows.

   If an AS_PATH attribute of a BGP-4 route carries AS_SET path
   segments, then the AS_PATH attribute of the BGP-3 route shall be
   constructed by treating the AS_SET segments as AS_SEQUENCE segments,
   with the resulting AS_PATH being a single AS_SEQUENCE. While this
   procedure loses set/sequence information, it doesn't affect
   protection for routing loops suppression, but may affect policies, if
   the policies are based on the content or ordering of the AS_PATH
   attribute.

   While injecting BGP-4 derived NLRI into BGP-3, one needs to be aware
   of the potential information explosion when a given IP prefix denotes
   a set of consecutive A/B/C class networks. Injection of BGP-4 derived
   NLRI that denotes IP subnets requires the BGP speaker to inject the
   corresponding network into BGP-3. The local system shall provide
   mechanisms to control the exchange of routing information between
   BGP-3 and BGP-4.  Specifically, a conformant implementation is
   required to support all of the following options when injecting BGP-4
   received routing information into BGP-3:

       - inject default only (0.0.0.0), no export of any other NLRI

       - allow controlled deaggregation, but only of specific routes;
         allow export of non-aggregated NLRI

       - allow export of only non-aggregated NLRI

   The exchange of routing information via BGP-3 between a BGP speaker
   participating in BGP-4 and a pure BGP-3 speaker may occur  only at
   the autonomous system boundaries. Within a single autonomous system
   BGP conversations between all the BGP speakers of that autonomous
   system have to be either BGP-3 or BGP-4, but not a mixture.

9. Operations over Switched Virtual Circuits

   When using BGP over Switched Virtual Circuit (SVC) subnetworks it may
   be desirable to minimize traffic generated by BGP. Specifically, it
   may be desirable to eliminate traffic associated with periodic
   KEEPALIVE messages.  BGP includes a mechanism for operation over
   switched virtual circuit (SVC) services which avoids keeping SVCs
   permanently open and allows it to eliminates periodic sending of
   KEEPALIVE messages.




Rekhter & Gross                                                [Page 12]

RFC 1772                   BGP-4 Application                  March 1995


   This section describes how to operate without periodic KEEPALIVE
   messages to minimise SVC usage when using an intelligent SVC circuit
   manager.  The proposed scheme may also be used on "permanent"
   circuits, which support a feature like link quality monitoring or
   echo request to determine the status of link connectivity.

   The mechanism described in this section is suitable only between the
   BGP speakers that are directly connected over a common virtual
   circuit.

9.1 Establishing a BGP Connection

   The feature is selected by specifying zero Hold Time in the OPEN
   message.

9.2 Circuit Manager Properties

   The circuit manager must have sufficient functionality to be able to
   compensate for the lack of periodic KEEPALIVE messages:

       - It must be able to determine link layer unreachability in a
         predictable finite period of a failure occurring.

       - On determining unreachability it should:

                - start a configurable dead timer (comparable to a
                  typical Hold timer value).

                - attempt to re-establish the Link Layer connection.


       - If the dead timer expires it should:

                - send an internal circuit DEAD indication to TCP.