rfc1164.txt

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

         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.

   Non-technical policy will typically override performance issues.

   For consistency, combinations of policies and route selection



Interconnectivity Working Group                                 [Page 6]

RFC 1164                   BGP - Application                   June 1990


   procedures that might result in equal cost paths must be resolved in
   a deterministic fashion.

   Fundamental to BGP usage is the rule that an AS advertizes to its
   neighboring ASs only those routes that it uses.  This rule reflects
   the "hop-by-hop" routing paradigm generally used by the current
   Internet.  Note that some policies that cannot be supported by the
   "hop-by-hop" routing paradigm and which require such techniques as
   source routing to enforce.  For example, BGP does not enable one AS
   to send traffic to a neighbor AS intending that that traffic take a
   different route from that taken by traffic originating in the
   neighbor AS.  On the other hand, BGP can support any policy
   conforming to the "hop-by-hop" routing paradigm.  Since the current
   Internet uses only the "hop-by-hop" routing paradigm and since BGP
   can support any policy that conforms to that paradigm, BGP is highly
   applicable as an inter-AS routing protocol for the current Internet.

4. Operational Issues

4.1 Path Selection

   One of the major tasks of a BGP speaker for a given AS at a given
   connection is to evaluate different paths to a destination network
   from its border gateways at that connection, select the best one, and
   then advertise it to all of its BGP neighbors at that same connection
   (subject to policy constraints).  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 ASs that can be used to
   evaluate external paths.  Rather, each AS may have its own set of
   criteria for path evaluation.

   A BGP speaker within an Autonomous System builds a routing database
   consisting of the set of all feasible paths and the list of networks
   reachable through each path.  In an efficient implementation, it will
   be important to store and process these paths and bundle the networks
   reachable through them.  For purposes of precise discussion, however,
   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 in the set.  This will often, however, not be the case.
   All feasible paths must be maintained, and their maintenance speeds
   adaptation to the loss of the primary path, but only the primary path
   at any given time will ever be advertised.




Interconnectivity Working Group                                 [Page 7]

RFC 1164                   BGP - Application                   June 1990


   The path selection process can be formalized by defining a partial
   order over the set of all possible 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 can be specified in a configuration file.

   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.

   The criteria used to assign a degree of preference to a path can be
   classified as primitive or compound.  Possible primitive criteria
   include:

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

      -  Presence or absence of a certain AS or ASs 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 ASs and may try to avoid or prefer
         them.

      -  Path origin.  A path whose endpoint is internal to the last AS
         on the path (BGP is used over the entire 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.

      -  Policy consideration.  BGP supports policy based routing based



Interconnectivity Working Group                                 [Page 8]

RFC 1164                   BGP - Application                   June 1990


         on the policy based distribution of routing information defined
         in RFC 1104 [2].  A BGP gateway 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.

   Metrics based on compound criteria can be computed as a weighted
   combination of the degree of preferences of primitive criteria.  The
   use of compound criteria should be done with extreme caution since it
   involves comparing potentially uncomparable quantities.

4.2 Syntax and Semantics for BGP Configuration Files

   A major task in using BGP is thus to assign a degree of preference to
   each available AS-path.  This degree of preference will generally be
   a function of the number of ASs in the path, properties of the
   specific ASs in the path, the origin of the route, and properties of
   the specific border router to be used in the first hop.  In this
   section we consider how a network administrator might articulate this
   function by means of a configuration file.  In the future, we can
   imagine using tools based on network management protocols such as
   SNMP for this task, but the protocols do not currently support this
   ability.

   In addition to controlling the selection of the best path to a given
   network, the network administrator must control the advertisement of
   this best path to neighboring ASs.  Therefore, path selection and
   path distribution emerge as the two key aspects of policy expression
   in BGP usage.

   Since different aspects of one AS's policy interact, and since the
   policies of different ASs interact, it is important to facilitate the
   analysis of such interactions by means of high-quality and consistent
   tools.

   There is also a need for tools to translate the expression of the
   network administrator's policy to some technical mechanism within a
   BGP speaker to implement that policy.

   These factors suggest that there should be a globally consistent way
   of describing policies in the configuration file.  The syntax and
   semantics of these policies should be capable of expressing the path
   selection phase within the local AS as well as the path
   redistribution phase to other ASs.

   Because it may be desirable to coordinate routing policy at an
   external level, it may prove worthwhile to create a language to
   describe this information in a globally consistent way.  Policies



Interconnectivity Working Group                                 [Page 9]

RFC 1164                   BGP - Application                   June 1990


   expressed in such a language could conceivably be used by some high-
   level tools to analyze the interaction among the routing policies of
   different Autonomous Systems.

   The following defines one possible syntax and semantics for
   describing AS path policies from the point of view of the local AS.
   Alternative syntaxes with equivalent richness of functionality are
   not precluded.  Other mechanisms may be needed to provide a fully
   functional configuration language.

   A complete AS path, supplied by BGP, provides the most important
   mechanism for policy enforcement.  Assigning a degree of preference
   to a particular AS path can be modelled as a matching between this
   path and one or more predefined AS path patterns.  Each predefined AS
   path pattern has a degree of preference that will be assigned to any
   AS path that matches it.

   Since patterns are naturally expressed by regular expressions, one
   can use regular expressions over the alphabet of AS numbers to define
   AS path patterns and, therefore, to formulate policies.

   Since certain constructs occur frequently in regular expressions, the
   following notational shorthand (operators) is defined:

      .  matches any AS number.  To improve readability, "." can be
         replaced by "any" so long as this does not introduce ambiguity.

      *  a regular expression followed by * means zero or more
         repetitions

      +  a regular expression followed by + means one or more
         repetitions

      ?  a regular expression followed by ? means zero or one repetition

      |  alternation

      () parentheses group subexpressions--an operator, such as * or
         works on a single element or on a regular expression enclosed
         in parentheses

      {m,n}  a regular expression followed by {m,n} (where m and n are
         both non-negative integers and m <= n) means at least m and at
         most n repetitions.

      {m}  a regular expression followed by {m} (where m is a positive
         integer) means exactly m repetitions.




Interconnectivity Working Group                                [Page 10]

RFC 1164                   BGP - Application                   June 1990


      {m,} a regular expression followed by {m,} (where m is a positive
         integer) means m or more repetitions.

Any regular expression is generated by these rules.

The Policy Based Routing Language can then be defined as follows:

      <Policy-Based-Routing> ::= { <policy-statement> }

      Semantics: each policy statement might cause a given possible BGP
      advertisement (possibility) to be installed into the routing table
      as the route to a given (set of) networks.  Thus, an empty
      Policy-Based-Routing means that no possibilities will be accepted.

      <policy-statement> ::=
                  <policy-expression> '=' <dop-expression> ';'

      Semantics: if a given possibility matches the policy-expression,
      then that possibility will be accepted with a degree of preference
      denoted by the integer value dop-expression.

      <policy-expression> ::=
              <policy-term> |
              <policy-term> <policy-operator> <policy-term>

      <policy-term> ::=
              <network-list> <AS-path> <origin> <distribution-list> |
              '(' <policy-expression> ')' |
              NOT <policy-expression> |
              <>

      <policy-operator> ::= OR | AND

      Semantics: the intersection of the network list of a possibility
      and the network-list must be non-empty; the AS-path of the
      possibility must match the AS-path as a sequence; the origin of
      the possibility must be a member of the origin set; if these
      conditions are met, the route denoted by the possibility is
      accepted as a possible route to those networks of the intersection
      of the possibility network list and the network-list.

      <AS-path> ::= "regular expression over AS numbers"

      Semantics: the AS-path of the possibility must be generated by the
      regular expression <AS-path>.






Interconnectivity Working Group                                [Page 11]

RFC 1164                   BGP - Application                   June 1990


      <network-list> ::= '<' { network network-list } '>' |
                         '<' ANY '>'

      Semantics: A non-empty sequence enumerates the network numbers of
      the network-list; ANY denotes the set of all network numbers.

      <origin> ::= IGP | EGP | INCOMPLETE | ANY

      Semantics: origin enumerates the sequence of acceptable origins;
      ANY denotes the set of all origins.

      <distribution-list> ::= '<' { AS } '>' |
                              '<' ANY '>'

      Semantics: if a given possibility as accepted and installed into
      the routing table, then distribution-list is the set of
      (neighboring) autonomous systems to whose border routers we will
      distribute the BGP-derived routes.

      <dop-expression> ::= <dop-term> |
                           <dop-term> '+' <dop-term> |
                           <dop-term> '-' <dop-term> |
                           <dop-term> '*' <dop-term> |
                           <dop-term> '/' <dop-term> |