rfc1268.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 731 行 · 第 1/3 页

   as External BGP, and with neighbors in the same AS as Internal BGP.

   There can be as many BGP speakers as deemed necessary within an AS.
   Usually, if an AS has multiple connections to other AS's, multiple
   BGP speakers are needed. All BGP speakers representing the same AS
   must give a consistent image of the AS to the outside. This requires
   that the BGP speakers have consistent routing information among them.
   These gateways can communicate with each other via BGP or by other
   means. The policy constraints applied to all BGP speakers within an
   AS must be consistent. Techniques such as using tagged IGP (see
   A.2.2) may be employed to detect possible inconsistencies.

   In the case of External BGP, the BGP neighbors must belong to
   different AS's, but share a common network. This common network
   should be used to carry the BGP messages between them. The use of BGP
   across an intervening AS invalidates the AS path information. An
   Autonomous System number must be used with BGP to specify which
   Autonomous System the BGP speaker belongs to.

4. Policy Making with BGP

   BGP provides the capability for enforcing policies based on various
   routing preferences and constraints. Policies are not directly
   encoded in the protocol. Rather, policies are provided to BGP in the
   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



BGP Working Group                                               [Page 5]

RFC 1268           Application of BGP in the Internet       October 1991


   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 not advertising routes to networks other
         than those directly connected to it.)

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

5. Path Selection with BGP

   One of the major tasks of a BGP speaker is to evaluate different
   paths to a destination network from its border gateways at that
   connection, select the best one, apply applicable policy constraints,
   and then advertise it to all of its BGP neighbors at that same
   connection. The key issue is how different paths are evaluated and
   compared.



BGP Working Group                                               [Page 6]

RFC 1268           Application of BGP in the Internet       October 1991


   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 networks reachable through each path.
   For purposes of precise discussion, it's useful to consider the set
   of feasible paths for a given destination network. 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 partial
   order over the set of all feasible paths to a given destination
   network. One way to define this partial 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.

   In actual BGP implementations, criteria for assigning degree of
   preferences to a path are specified in 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 at configuration).

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

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

      - Policy consideration. 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.




BGP Working Group                                               [Page 7]

RFC 1268           Application of BGP in the Internet       October 1991


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

6. 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 provides support for quite complex
   routing policies. However, it is not required for all BGP
   implementations to 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 network.  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).

      2. BGP implementations should allow an AS to prefer a particular
         path to a destination (when more than one path is available).
         This function should be implemented by allowing system
         administrators to assign "weights" to AS's, and making route
         selection process to select a route with the lowest "weight"
         (where "weight" of a route is defined as a sum of "weights" of



BGP Working Group                                               [Page 8]

RFC 1268           Application of BGP in the Internet       October 1991


         all AS's in the AS_PATH path attribute associated with that
         route).

      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 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".

7. Conclusion

   The BGP protocol provides a high degree of control and flexibility
   for doing interdomain routing while enforcing policy and performance
   constraints and avoiding routing loops. The guidelines presented here
   will provide a starting point for using BGP to provide more
   sophisticated and manageable routing in the Internet as it grows.

Appendix A. The Interaction of BGP and an IGP

   This section outlines methods by which BGP can exchange routing
   information with an IGP. The methods outlined here are not proposed
   as part of the standard BGP usage at this time.  These methods are
   outlined for information purposes only.  Implementors may want to
   consider these methods when importing IGP information.

   This is general information that applies to any generic IGP.
   Interaction between BGP and any specific IGP is outside the scope of
   this section.  Methods for specific IGP's should be proposed in
   separate documents.  Methods for specific IGP's could be proposed for
   standard usage in the future.

Overview