rfc2622.txt

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

      possible.  The following examples illustrate the most common
      cases, using the import attribute of the aut-num class.  In the
      following example 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2.

 (1) aut-num: AS1
     import: from AS2 7.7.7.2 at 7.7.7.1 accept { 128.9.0.0/16 }

   In the following example 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2
   and 7.7.7.3.

 (2) aut-num: AS1
     import: from AS2 at 7.7.7.1 accept { 128.9.0.0/16 }


   In the following example 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2
   and 7.7.7.3, and 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2.

 (3) aut-num: AS1
     import: from AS2 accept { 128.9.0.0/16 }

   In the following example 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2
   and 9.9.9.3.







Alaettinoglu, et al.        Standards Track                    [Page 25]

RFC 2622                          RPSL                         June 1999


 (4) as-set: AS-FOO
     members: AS2, AS3

     aut-num: AS1
     import: from AS-FOO      at 9.9.9.1 accept { 128.9.0.0/16 }

   In the following example 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2
   and 9.9.9.3, and 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2 and
   7.7.7.3.

 (5) aut-num: AS1
     import: from AS-FOO                 accept { 128.9.0.0/16 }

   In the following example AS1 imports 128.9.0.0/16 from AS3 at router
   9.9.9.1

 (6) aut-num: AS1
     import: from AS-FOO and not AS2 at not 7.7.7.1
             accept { 128.9.0.0/16 }

   This is because "AS-FOO and not AS2" equals AS3 and "not 7.7.7.1"
   equals 9.9.9.1.

   In the following example 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2
   and 9.9.9.3.

 (7) peering-set: prng-bar
     peering: AS1 at 9.9.9.1

     peering-set: prng-foo
     peering: prng-bar
     peering: AS2 at 9.9.9.1

     aut-num: AS1
     import: from prng-foo accept { 128.9.0.0/16 }
















Alaettinoglu, et al.        Standards Track                    [Page 26]

RFC 2622                          RPSL                         June 1999


6 aut-num Class

   Routing policies are specified using the aut-num class.  The
   attributes of the aut-num class are shown in Figure 23.  The value of
   the aut-num attribute is the AS number of the AS described by this
   object.  The as-name attribute is a symbolic name (in RPSL name
   syntax) of the AS. The import, export and default routing policies of
   the AS are specified using import, export and default attributes
   respectively.

   Attribute  Value                  Type
   aut-num    <as-number>            mandatory, single-valued, class key
   as-name    <object-name>          mandatory, single-valued
   member-of  list of <as-set-names> optional, multi-valued
   import     see Section 6.1        optional, multi valued
   export     see Section 6.2        optional, multi valued
   default    see Section 6.5        optional, multi valued

                    Figure 23:  aut-num Class Attributes

6.1 import Attribute:  Import Policy Specification

   In RPSL, an import policy is divided into import policy expressions.
   Each import policy expression is specified using an import attribute.
   The import attribute has the following syntax (we will extend this
   syntax later in Sections 6.3 and 6.6):

   import: from <peering-1> [action <action-1>]
            . . .
            from <peering-N> [action <action-N>]
            accept <filter>

   The action specification is optional.  The semantics of an import
   attribute is as follows: the set of routes that are matched by
   <filter> are imported from all the peers in <peerings>; while
   importing routes at <peering-M>, <action-M> is executed.

  E.g.
    aut-num: AS1
    import: from AS2 action pref = 1; accept { 128.9.0.0/16 }

   This example states that the route 128.9.0.0/16 is accepted from AS2
   with preference 1.  We already presented how peerings (see Section
   5.6) and filters (see Section 5.4) are specified.  We next present
   how to specify actions.






Alaettinoglu, et al.        Standards Track                    [Page 27]

RFC 2622                          RPSL                         June 1999


6.1.1 Action Specification

   Policy actions in RPSL either set or modify route attributes, such as
   assigning a preference to a route, adding a BGP community to the BGP
   community path attribute, or setting the MULTI-EXIT-DISCRIMINATOR
   attribute.  Policy actions can also instruct routers to perform
   special operations, such as route flap damping.

   The routing policy attributes whose values can be modified in policy
   actions are specified in the RPSL dictionary.  Please refer to
   Section 7 for a list of these attributes.  Each action in RPSL is
   terminated by the semicolon character (';').  It is possible to form
   composite policy actions by listing them one after the other.  In a
   composite policy action, the actions are executed left to right.  For
   example,

 aut-num: AS1
 import: from AS2
         action pref = 10; med = 0; community.append(10250, 3561:10);
         accept { 128.9.0.0/16 }

   sets pref to 10, med to 0, and then appends 10250 and 3561:10 to the
   BGP community path attribute.  The pref attribute is the inverse of
   the local-pref attribute (i.e. local-pref == 65535 - pref).  A route
   with a local-pref attribute is always preferred over a route without
   one.

 aut-num: AS1
 import: from AS2 action pref = 1;
         from AS3 action pref = 2;
         accept AS4

   The above example states that AS4's routes are accepted from AS2 with
   preference 1, and from AS3 with preference 2 (routes with lower
   integer preference values are preferred over routes with higher
   integer preference values).

 aut-num: AS1
 import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 1;
         from AS2                    action pref = 2;
         accept AS4

   The above example states that AS4's routes are accepted from AS2 on
   peering 7.7.7.1-7.7.7.2 with preference 1, and on any other peering
   with AS2 with preference 2.






Alaettinoglu, et al.        Standards Track                    [Page 28]

RFC 2622                          RPSL                         June 1999


6.2 export Attribute:  Export Policy Specification

   Similarly, an export policy expression is specified using an export
   attribute.  The export attribute has the following syntax:

    export: to <peering-1> [action <action-1>]
            . . .
            to <peering-N> [action <action-N>]
            announce <filter>

   The action specification is optional.  The semantics of an export
   attribute is as follows:  the set of routes that are matched by
   <filter> are exported to all the peers specified in <peerings>; while
   exporting routes at <peering-M>, <action-M> is executed.

  E.g.
    aut-num: AS1
    export: to AS2 action med = 5; community .= { 70 };
            announce AS4

   In this example, AS4's routes are announced to AS2 with the med
   attribute's value set to 5 and community 70 added to the community
   list.

   Example:

    aut-num: AS1
    export: to AS-FOO announce ANY

   In this example, AS1 announces all of its routes to the ASes in the
   set AS-FOO.

6.3 Other Routing Protocols, Multi-Protocol Routing Protocols, and
   Injecting Routes Between Protocols

   The more complete syntax of the import and export attributes are as
   follows:

    import: [protocol <protocol-1>] [into <protocol-2>]
            from <peering-1> [action <action-1>]
            . . .
            from <peering-N> [action <action-N>]
            accept <filter>
    export: [protocol <protocol-1>] [into <protocol-2>]
            to <peering-1> [action <action-1>]
            . . .
            to <peering-N> [action <action-N>]
            announce <filter>



Alaettinoglu, et al.        Standards Track                    [Page 29]

RFC 2622                          RPSL                         June 1999


   Where the optional protocol specifications can be used for specifying
   policies for other routing protocols, or for injecting routes of one
   protocol into another protocol, or for multi-protocol routing
   policies.  The valid protocol names are defined in the dictionary.
   The <protocol-1> is the name of the protocol whose routes are being
   exchanged.  The <protocol-2> is the name of the protocol which is
   receiving these routes.  Both <protocol-1> and <protocol-2> default
   to the Internet Exterior Gateway Protocol, currently BGP.

   In the following example, all interAS routes are injected into RIP.

 aut-num: AS1
 import: from AS2 accept AS2
 export: protocol BGP4 into RIP
         to AS1 announce ANY

   In the following example, AS1 accepts AS2's routes including any more
   specifics of AS2's routes, but does not inject these extra more
   specific routes into OSPF.

 aut-num: AS1
 import: from AS2 accept AS2^+
 export: protocol BGP4 into OSPF
         to AS1 announce AS2

   In the following example, AS1 injects its static routes (routes which
   are members of the set AS1:RS-STATIC-ROUTES) to the interAS routing
   protocol and appends AS1 twice to their AS paths.

 aut-num: AS1
 import: protocol STATIC into BGP4
         from AS1 action aspath.prepend(AS1, AS1);
         accept AS1:RS-STATIC-ROUTES

   In the following example, AS1 imports different set of unicast routes
   for multicast reverse path forwarding from AS2:

 aut-num: AS1
 import: from AS2 accept AS2
 import: protocol IDMR
         from AS2 accept AS2:RS-RPF-ROUTES










Alaettinoglu, et al.        Standards Track                    [Page 30]

RFC 2622                          RPSL                         June 1999


6.4 Ambiguity Resolution

   It is possible that the same peering can be covered by more that one
   peering specification in a policy expression.  For example:

 aut-num: AS1
 import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 2;
         from AS2 7.7.7.2 at 7.7.7.1 action pref = 1;
         accept AS4

   This is not an error, though definitely not desirable.  To break the
   ambiguity, the action corresponding to the first peering
   specification is used.  That is the routes are accepted with
   preference 2.  We call this rule as the specification-order rule.

   Consider the example:

 aut-num: AS1
 import: from AS2                    action pref = 2;
         from AS2 7.7.7.2 at 7.7.7.1 action pref = 1; dpa = 5;
         accept AS4

   where both peering specifications cover the peering 7.7.7.1-7.7.7.2,
   though the second one covers it more specifically.  The specification
   order rule still applies, and only the action "pref = 2" is executed.
   In fact, the second peering-action pair has no use since the first
   peering-action pair always covers it.  If the intended policy was to
   accept these routes with preference 1 on this particular