rfc2280.txt

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

    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.

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>



Alaettinoglu, et. al.       Standards Track                    [Page 24]

RFC 2280                          RPSL                      January 1998


   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>

   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.




Alaettinoglu, et. al.       Standards Track                    [Page 25]

RFC 2280                          RPSL                      January 1998


   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

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.




Alaettinoglu, et. al.       Standards Track                    [Page 26]

RFC 2280                          RPSL                      January 1998


   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 peering and
   with preference 2 in all other peerings, the user should have
   specified:

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

   It is also possible that more than one policy expression can cover
   the same set of routes for the same peering.  For example:

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

   In this case, the specification-order rule is still used.  That is,
   AS4's routes are accepted from AS2 with preference 2.  If the filters
   were overlapping but not exactly the same:

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

   the AS4's routes are accepted from AS2 with preference 2 and however
   AS5's routes are also accepted, but with preference 1.

   We next give the general specification order rule for the benefit of
   the RPSL implementors.  Consider two policy expressions:

    aut-num: AS1
    import: from peerings-1 action action-1 accept filter-1
    import: from peerings-2 action action-2 accept filter-2

   The above policy expressions are equivalent to the following three
   expressions where there is no ambiguity:



Alaettinoglu, et. al.       Standards Track                    [Page 27]

RFC 2280                          RPSL                      January 1998


aut-num: AS1
import: from peerings-1 action action-1 accept filter-1
import: from peerings-3 action action-2 accept filter-2 AND NOT filter-1
import: from peerings-4 action action-2 accept filter-2

   where peerings-3 are those that are covered by both peerings-1 and
   peerings-2, and peerings-4 are those that are covered by peerings-2
   but not by peerings-1 ("filter-2 AND NOT filter-1" matches the routes
   that are matched by filter-2 but not by filter-1).

   Example:

    aut-num: AS1
    import: from AS2 7.7.7.2 at 7.7.7.1
            action pref = 2;
            accept {128.9.0.0/16}
    import: from AS2
            action pref = 1;
            accept {128.9.0.0/16, 75.0.0.0/8}

   Lets consider two peerings with AS2, 7.7.7.1-7.7.7.2 and 9.9.9.1-
   9.9.9.2.  Both policy expressions cover 7.7.7.1-7.7.7.2.  On this
   peering, the route 128.9.0.0/16 is accepted with preference 2, and
   the route 75.0.0.0/8 is accepted with preference 1.  The peering
   9.9.9.1-9.9.9.2 is only covered by the second policy expressions.
   Hence, both the route 128.9.0.0/16 and the route 75.0.0.0/8 are
   accepted with preference 1 on peering 9.9.9.1-9.9.9.2.

   Note that the same ambiguity resolution rules also apply to export
   and default policy expressions.

6.5 default Attribute:  Default Policy Specification

   Default routing policies are specified using the default attribute.
   The default attribute has the following syntax:

       default: to <peering> [action <action>] [networks <filter>]

   The <action> and <filter> specifications are optional.  The semantics
   are as follows: The <peering> specification indicates the AS (and the
   router if present) is being defaulted to; the <action> specification,
   if present, indicates various attributes of defaulting, for example a
   relative preference if multiple defaults are specified; and the
   <filter> specifications, if present, is a policy filter.  A router
   chooses a default router from the routes in its routing table that
   matches this <filter>.

   In the following example, AS1 defaults to AS2 for routing.



Alaettinoglu, et. al.       Standards Track                    [Page 28]

RFC 2280                          RPSL                      January 1998


    aut-num: AS1
    default: to AS2

   In the following example, router 7.7.7.1 in AS1 defaults to router
   7.7.7.2 in AS2.

    aut-num: AS1
    default: to AS2 7.7.7.2 at 7.7.7.1

   In the following example, AS1 defaults to AS2 and AS3, but prefers
   AS2 over AS3.

    aut-num: AS1
    default: to AS2 action pref = 1;
    default: to AS3 action pref = 2;

   In the following example, AS1 defaults to AS2 and uses 128.9.0.0/16
   as the default network.

    aut-num: AS1
    default: to AS2 networks { 128.9.0.0/16 }

6.6 Structured Policy Specification

   The import and export policies can be structured.  We only reccomend
   structured policies to advanced RPSL users.  Please feel free to skip
   this section.

   The syntax for a structured policy specification is the following:

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

      <import-term> ::=  <import-factor> |
                         LEFT-BRACE
                         <import-factor>
                         . . .
                         <import-factor>
                         RIGHT-BRACE

      <import-expression> ::= <import-term>                            |
                              <import-term> EXCEPT <import-expression> |
                              <import-term> REFINE <import-expression>

      import: [protocol <protocol1>] [into <protocol2>]
              <import-expression>



Alaettinoglu, et. al.       Standards Track                    [Page 29]

RFC 2280                          RPSL                      January 1998


   Please note the semicolon at the end of an <import-factor>.  If the
   policy specification is not structured (as in all the examples in
   other sections), this semicolon is optional.  The syntax and
   semantics for an <import-factor> is already defined in Section 6.1.

   An <import-term> is either a sequence of <import-factor>'s enclosed
   within matching braces (i.e. `{' and `}') or just a single <import-
   factor>.  The semantics of an <import-term> is the union of <import-
   factor>'s using the specification order rule.  An <import-expression>
   is either a single <import-term> or an <import-term> followed by one
   of the keywords "except" and "refine", followed by another <import-
   expression>.  Note that our definition allows nested expressions.
   Hence there can be exceptions to exceptions, refinements to
   refinements, or even refinements to exceptions, and so on.

   The semantics for the except operator is as follows: The result of an
   except operation is another <import-term>.  The resulting policy set
   contains the policies of the right hand side but their filters are
   modified to only include the routes also matched by the left hand
   side.  The policies of the left hand side are included afterwards and
   their filters are modified to exclude the routes matched by th