rfc1164.txt

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

                           REJECT

      <dop-term> ::= <integer> |
                     <function> |
                     '(' <dop-expression> ')'

      Semantics: if a possibility matches with degree of preference
      REJECT, then that possibility will not be used.  Otherwise, the
      integer value of the degree of preference indicates the degree of
      preference of the possibility, with higher values preferred over
      lower ones.

   White spaces can be used between symbols to improve readability.
   "<>" denotes the empty sequence.

   There are two built-in functions, PathLength() and PathWeight().
   PathLength() takes the AS path as an argument and returns the number
   of ASs in that path.  PathWeight() takes the AS path and an AS weight
   table as arguments and returns the sum of weights of the ASs in the
   AS path as defined by the AS weight table.  In order to preserve
   determinism, the AS weight table must always have a default weight
   which will be assigned to any AS which is not in that table.

   The AS path, as used above, is constructed from right to left which



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


   is consistent with BGP), so that the most recent AS in the path
   occupies the leftmost position.

   Each network (and its associated complete AS path) received from
   other BGP neighbors is matched against local Routing Policies.

   If either no match occurs or the degree of preference associated with
   the matched policy is REJECT, then the received information is
   rejected.  Otherwise, a degree of preference associated with the
   matched policy is assigned to that path.  Notice that the process
   terminates on the first successful match.  Therefore, policy-terms
   should be ordered from more specific to more general.

   The semantics of a matched policy is as follows:  If a network in
   <network-list> that was originally introduced into BGP from <origin>
   is received via <AS-path>, that network should be redistributed to
   all ASs in <distribution-list>.

   The following examples (some taken from RFC 1102 [3]) illustrate how
   Policy Terms can be written.

   In the following topology, H elements are hosts, G elements are
   Policy Gateways running BGP, and numbered elements are ASs.

        H1 --- 1 -G12...G21 - 2 -- G23...G32 -- 3 ----- H2
               |                                |
               |                                |
               |                                |
               |- G14...G41 - 4 -- G43...G34 ---|- G35...G53 - 5
                              |                                |
                              |                                |
                              |                               H4
                              H3

   In this picture, there are four hosts, ten gateways, and five
   Autonomous Systems.  Gateways G12 and G14 belong to AS 1.  Gateways
   G21 and G23 belong to AS 2.  Gateways G41 and G43 belongs to AS 4.
   Gateways G32, G34, and G35 belong to AS 3.  Gateway G53 belongs to AS
   5.  Dashed lines denote intra-AS connections.  Dotted lines denote
   inter-AS connections.

   First, consider AS 2.  It has no hosts attached, and models a transit
   service, such as the NSFNET backbone network.  It may have a very
   simple policy: it will carry any traffic between any two ASs, without
   further constraint.  If AS 1 and AS 3 are neighboring domains, then
   its policy term could be written as:

      AS 2: < ANY > < (1 | 3) .* > < IGP > < 1 3 > = 10



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


   The first component in this policy, the network list

      < ANY >

   says that any network is subject to this policy.  The second
   component, the AS path

      < (1 | 3) .* >

   says that routing information that came from either AS 1 or AS 3
   matches this policy, including routes from ASs that lie beyond AS 1
   and AS 3.  The third component, the origin

      < IGP >

   says that this route must be interior with respect to the originating
   AS, implying that routes imported via EGP or some other mechanism
   would not match this policy.  The fourth component, the distribution
   list

      < 1  3 >

   says that this route may be redistributed to both AS 1 and AS 3.
   Finally, the degree of preference assigned to any route which matches
   this policy is set to 10.

   To improve readability, the above policy can be rewritten as:

      AS 2: < ANY > < (1 | 3) ANY* > < IGP > < 1  3 > = 10

   Next, consider AS 3.  It is willing to provide transit service to AS
   4 and AS 5, presumably due to multilateral agreements.  AS 3 should
   set its policy as follows:

      AS 3: < ANY > < (4 | 5) > < IGP > < 2  4  5 > = 10
      AS 3: < ANY > < 2  .* > < ANY > < 4  5 > = 10
      AS 3: < ANY > < 3 > < ANY > < 2  4  5 > = 10

   This would allow AS 3 to distribute internal routes received from ASs
   4 and 5 to ASs 2, 4, and 5, and all backbone routes through AS 2
   would be distributed to ASs 4 and 5.  AS 3 would advertise its own
   networks to ASs 2, 4, and 5.  Hosts in AS 4 and AS 5 would be able to
   reach each other, as well as hosts in ASs 1 and 3 and anything beyond
   them.  AS 3 allows any origin in routes from AS 2.  This implies that
   AS 3 trusts AS 2 to impose policy on routes imported by means other
   than BGP.  Note that although the policy statement would appear to
   allow AS 3 to send ASs 4 and 5 their own routes, the BGP protocol
   would detect this as a routing loop and prevent it.



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


   Now consider AS 1.  AS 1 wishes to use the backbone service provided
   by AS 2, and is willing to carry transit traffic for AS 4.  The
   policy statements for AS 1 might read:

      AS 1: < ANY > < 4 > < IGP > < 2 > = 150
      AS 1: < ANY > < 2  .* > < ANY > < 4 > = 150
      AS 1: < ANY > < 1 > < ANY > < 2  4 > = 150

   AS 1 will redistribute all routes learned from the AS 2 backbone to
   AS 4, and vice versa, and distribute routes to its own networks to
   both AS 2 and AS 4.  The degree of preference assigned to any route
   which matches this policy is set to 150.

   AS 5 is a more interesting case.  AS 5 wishes to use the backbone
   service, but is not directly connected to AS 2.  Its policy
   statements could be as follows:

      AS 5: < ANY > < 3  4 > < IGP > < > = 10
      AS 5: < ANY > < 3  2  .* > < . > < > = 10
      AS 5: < ANY > < 5 > < . > < 3 > = 10

   This policy imports routes through AS 2 and AS 3 into AS 5, and
   allows AS 5 and AS 4 to communicate through AS 3.  Since AS 5 does
   not redistribute any routes other than its own, it is a stub AS.
   Note that AS 5 does not trust AS 3 to advertise only routes through
   AS 2, and thus applies its own filter to ensure that it only uses the
   backbone.  This lack of trust makes it necessary to add the second
   policy term.

   AS 4 is a good example of a multihomed AS.  AS 4 wishes to use AS 3
   as is primary path to the backbone, with AS 1 as a backup.
   Furthermore, AS 4 does not wish to provide any transit service
   between ASs 1 and 3.  Its policy statement could read:

      AS 4: < ANY > < 3  .* > < ANY > < > = 10
      AS 4: < ANY > < 1  .* > < ANY > < > = 20
      AS 4: < ANY > < 4 > < ANY > < 1  3 > = 10

   Paths to any network through AS 3 are preferred, but AS 1 will be
   used as a backup if necessary.  Note that since AS 4 trusts AS 3 to
   provide it with reasonable routes, it is not necessary to explicitly
   import routes from AS 5.  Since the redistribution terms are null
   except for networks within AS 4, AS 4 will never carry any transit
   traffic.

   Given the topology and policies described above, it becomes apparent
   that two paths of equal preference would be available from AS 2 to
   any of the networks in AS 4.  Since ties are not allowed, an



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


   arbitrary tie-breaking mechanism would come into play (as described
   above), which might result in less than optimal routes to some
   networks.  An alternative mechanism that would provide optimal routes
   while still allowing fallback paths would be to provide network-by-
   network policies in specific cases, and explicit tie-breaking
   policies for the remaining networks.  For example, the policies for
   AS 2 could be rewritten as follows:

      AS 2: < 35 > < 1  .* > < IGP > < 3 > = 10
      AS 2: < 35 > < 3  .* > < IGP > < 1 > = 20
      AS 2: < ANY > < 1  .* > < IGP > < 3 > = 20
      AS 2: < ANY > < 3  .* > < IGP > < 1 > = 10

   Paths to network 35 through AS 1 would be preferred, with AS 3 as a
   fallback; paths to all other networks through AS 3 would be preferred
   over those through AS 1.  Such optimizations may become arbitrarily
   complex.

   There may be other, simpler ways to assign a degree of preference to
   an AS path.

   The simplest way to assign a degree of preference to a particular
   path is to use the number of ASs in the AS path as the degree of
   preference.  This approach reflects the heuristic that shorter paths
   are usually better than longer ones.  This policy can be implemented
   by using the PathLength() built-in function in the following policy
   statement:

      < ANY > < .* > < ANY > < ANY > = PathLength(ASpath)

   This policy assigns to any network with an arbitrary AS path a degree
   of preference equal to the number of ASs in the AS path; it then
   redistributes this information to all other BGP speakers. As an
   example, an AS path which traverses three different Autonomous
   Systems will be assigned the degree of preference 3.

   Another approach is to assign a certain degree of preference to each
   individual AS, and then determine the degree of preference of a
   particular AS path as the sum of the degree of preferences of the ASs
   in that path.  Note that this approach does not require the
   assignment of a specific degree of preference to every AS in the
   Internet.  For ASs with an unknown degree of preference, a default
   can be used.  This policy can be implemented by using the
   PathWeight() built-in function in the following policy statement:

      < ANY > < .* > < ANY > < ANY >
                           = PathWeight(ASpath, ASWeightTable)




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


   As an example, if Autonomous Systems 145 and 55 have 10 and 15 as
   their weights in the ASWeightTable, and if the default degree of
   preference in the ASWeightTable is 50, then an AS path that traverses
   Autonomous Systems 145, 164, and 55 will be assigned degree of
   preference 75.

   The above examples demonstrate some of the simple policies that can
   be implemented with BGP.  In general, very sophisticated policies
   based on partial or complete AS path discrimination can be written
   and enforced.  It should be emphasized that movement toward more
   sophisticated policies will require parallel effort in creating more
   sophisticated tools for policy interaction analysis.

5. The Interaction of BGP and an IGP

5.1 Overview

   By definition, all transit ASs must be able to carry traffic external
   to that AS (neither the source nor destination host belongs to the
   AS).  This requires a certain degree of interaction and coordination
   between the Interior Gateway Protocol (IGP) used by that particular
   AS and BGP.  In general, traffic exterior to a given AS is going to
   pass through both interior gateways (gateways that support IGP only)
   and border gateways (gateways that support both IGP and BGP).  All
   interior gateways receive information about external routes from one
   or more of the border gateways of the AS via the IGP.

   Depending on the mechanism used to propagate BGP information within a
   given AS, special care must be taken to ensure consistency between
   BGP and the IGP, since changes in state are likely to propagate at
   different rates across the AS.  There may be a time window between
   the moment when some border gateway (A) receives new BGP routing
   information which was originated from another border gateway (B)
   within the same AS, and the moment the IGP within this AS is capable
   of routing transit traffic to that border gateway (B).  During that
   time window, either incorrect routing or "black holes" can occur.

   In order to minimize such routing problems, border gateway (A) should
   not advertise a route to some exterior network X to all of its BGP
   neighbors in other ASs until all of the interior gateways within the
   AS are ready to route traffic destined to X via the correct exit
   border gateway (B).  In other words, interior routing should converge
   on the proper exit gateway before advertising routes via that exit
   gateway to other ASs.

5.2 Methods for Achieving Stable Interactions

   The following discussion outlines several techniques capable of



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


   achieving stable interactions between BGP and the IGP within an
   Autonomous System.

5.2.1 Propagation of BGP Information via the IGP

   While BGP can provide its own mechanism for carrying BGP information
   within an AS, one can also use an IGP to transport this information,
   as long as the IGP supports complete flooding of routing information
   (providing the mechanism to distribute the BGP information) and one-
   pass convergence (making the mechanism effectively atomic).  If an
   IGP is used to carry BGP information, then the period of