rfc2650.txt

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

   changing customer base, this mechanism will not scale well.

      route-set:   AS2:RS-ROUTES:AS3
      members:     7.7.0.0/16^16-19
      changed:     [e-mail]
      source:      RIPE

      Figure 7:  The route-set object

   Luckily RPSL supports the notion of a "route-set" which, as shown in
   Figure 7, can be used to specify the set of routes that will be
   accepted from a given customer.  Given this set (and a similar one
   for AS4), the manager of AS2 can now filter on the address space that
   will be accepted from their customers by modifying the import lines
   in the AS2 aut-num object as shown in Figure 8.

      import:      from AS1 accept ANY
      import:      from AS3 accept AS2:RS-ROUTES:AS3
      import:      from AS4 accept AS2:RS-ROUTES:AS4
      export:      to AS2:AS-CUSTOMERS announce ANY
      export:      to AS1 announce AS2 AS2:AS-CUSTOMERS

      Figure 8:  Policy in the AS2 aut-num object for address based
                 filtering on AS2 customers




Meyer, et al.                Informational                      [Page 7]

RFC 2650                 Using RPSL in Practice              August 1999


   Note that this is now only slightly more complex than the example in
   Figure 6.  Furthermore, nothing need be changed in the AS2 aut-num
   object due to address space changes for a customer, and this
   filtering can be supported without any changes to the AS1 aut-num
   object.  The additional complexity is due to the two route set names
   being different, otherwise we could have combined the two import
   statements into one.  Please note that the set names are constructed
   hierarchically.  The first AS number denotes whose sets these are,
   and the last AS number parameterize these sets for each peer.  RPSL
   allows the peer's AS number to be replaced by the keyword PeerAS.

   Hence,

      import:      from AS3 accept AS2:RS-ROUTES:PeerAS
      import:      from AS4 accept AS2:RS-ROUTES:PeerAS

   has the same meaning as the corresponding import statements in Figure
   6.  This lets us combine the two import statements into one as shown
   in Figure 9.

      import:      from AS1 accept ANY
      import:      from AS2:AS-CUSTOMERS accept AS2:RS-ROUTES:PeerAS
      export:      to AS2:AS-CUSTOMERS announce ANY
      export:      to AS1 announce AS2 AS2:AS-CUSTOMERS

      Figure 9:  Policy in the AS2 aut-num object using PeerAS

2.3 Including Interfaces in Peering Definitions

   In the above examples peerings were only given among ASes.  However,
   the peerings may be described in much more detail by RPSL, where
   peerings can be specified between physical routers using IP addresses
   in the import and export attributes.  Figure 10 shows a simple
   example in which AS1 and AS2 are connected to an exchange point IX.
   While AS1 has only one connection to the exchange point via a router
   interface with IP address 7.7.7.1, AS2 has two different connections
   with IP address 7.7.7.2 and 7.7.7.3.  The first AS may then define
   its routing policy in more detail by specifying its boundary router.

      +--------------------+                +--------------------+
      |            7.7.7.1 |-----+    +-----| 7.7.7.2            |
      |                    |     |    |     |                    |
      | AS1                |    ========    |                AS2 |
      |                    |    IX    |     |                    |
      |                    |          +-----| 7.7.7.3            |
      +--------------------+                +--------------------+

      Figure 10:  Including interfaces in peerings definitions



Meyer, et al.                Informational                      [Page 8]

RFC 2650                 Using RPSL in Practice              August 1999


      aut-num:   AS1
      import:    from AS2 at 7.7.7.1 accept <^AS2+$>

   Because AS1 has only one connection to the exchange point in this
   example, this specification does not differ from that in which no
   boundary router is specified.  However, AS1 might want to choose to
   accept only those announcements from AS2 which come from the router
   with IP address 7.7.7.2 and disregard those announcements from router
   7.7.7.3.  AS1 can specify this routing policy as follows:

      aut-num:   AS1
      import:    from AS2 7.7.7.2 at 7.7.7.1 accept <^AS2+$>

   By selecting certain pairs of routers in a peering specification,
   others can be denied.  If no routers are included in a policy clause
   then it is assumed that the policy applies to all peerings among the
   ASes involved.

2.4 Describing Simple Backup Connections

   The specification of peerings among ASes is not limited to one router
   for each AS. In figure 10 one of the two connections of AS2 to the
   exchange point IX might be used as backup in case the other
   connection fails.  Let us assume that AS1 wants to use the connection
   to router 7.7.7.2 of AS2 during regular operations, and router
   7.7.7.3 as backup.  In a router configuration this may be done by
   setting a local preference.  The equivalent in RPSL is a
   corresponding action definition in the peering description.  The
   action definitions are inserted directly before the accept keyword.

      aut-num:   AS1
      import:    from AS2 7.7.7.2 at 7.7.7.1 action pref=10;
                 from AS2 7.7.7.3 at 7.7.7.1 action pref=20;
                 accept <^AS2+$>

   pref is opposite to local-pref in that the smaller values are
   preferred over larger values.  Actions may also be defined without
   specifying IP addresses of routers.  If no routers are included in
   the policy clause then it is assumed that the actions are carried out
   for all peerings among the ASes involved.

   In the previous example AS1 controls where it sends its traffic and
   which connection is used as backup.  However, AS2 may also define a
   backup connection in an export clause:







Meyer, et al.                Informational                      [Page 9]

RFC 2650                 Using RPSL in Practice              August 1999


      aut-num:   AS2
      export:    to AS1 7.7.7.1 at 7.7.7.2 action med=10;
                 to AS1 7.7.7.1 at 7.7.7.3 action med=20;
                 announce <^AS2+$>

   The definition given here for AS2 is the symmetric counterpart to the
   routing policy of AS1.  The selection of routing information is done
   by setting the multi exit discriminator metric med.  Actually, med
   metrics will not be used in practice like this; they are more
   suitable for load balancing including backups.  For more details on
   med metrics refer to the BGP-4 RFC [7].  To use the med to achieve
   load balancing, one often sets it to the "IGP metric".  This is
   specified in RPSL as:

      aut-num:   AS2
      export:    to AS1 action med=igp_cost; announce <^AS2+$>

   Hence, both routers will set the med to the IGP metric at that
   router, causing some routes to be preferred at one of the routers and
   other routes at the other router.

2.5 Multi-Home Routing Policies using the community Attribute

   RFC 1998 [9] describes the use of the BGP community attribute to
   provide support for load balancing and backup connections of multi-
   homed autonomous systems.  In this section, we use stepwise
   refinement of an example to illustrate how those policies might be
   specified using RPSL.

   The basic premise of RFC 1998 is to use the BGP community attribute
   to allow a customer to configure the BGP "LOCAL_PREF" on a provider's
   routers.  This will allow the customer to influence the provider's
   route selection, normally by lowering the BGP "LOCAL_PREF" to
   indicate backup arrangements.

   In this example, we illustrate how AS1 (the provider) might specify
   their policy so that a customer (AS4) connected to two of AS1's
   direct customers (AS2 and AS3) might signal to AS1 which connection
   is to be preferred.

   AS1's base policy is to only accept routes from customers that are
   originated by the customer, or by the customer's customers.  This
   leads to a policy such as:








Meyer, et al.                Informational                     [Page 10]

RFC 2650                 Using RPSL in Practice              August 1999


      aut-num:     AS1
      import:      from AS2
                   accept (AS2 OR AS4) AND <^AS2+ AS4*$>
      import:      from AS3
                   accept (AS3 OR AS4) AND <^AS3+ AS4*$>
      import:      from AS5
                   accept AS5 AND <^AS5+$>

   Note that AS4 is a customer of AS2 and AS3, and AS5 does not have its
   own customers.

   Now suppose we want to add some policy to describe that if a customer
   tags a route with community 1:1 then AS1 will act on this to reduce
   the BGP "LOCAL_PREF" by 10.

   aut-num: AS1
   import:  from AS2
            action pref=10;
            accept (AS2 OR AS4) AND <^AS2+ AS4*$>
                    AND community.contains(1:1)
   import:  from AS2
            action pref=0;
            accept (AS2 OR AS4) AND <^AS2+ AS4*$>
   import:  from AS3
            action pref=10;
            accept (AS3 OR AS4) AND <^AS3+ AS4*$>
                    AND community.contains(1:1)
   import:  from AS3
            action pref=0;
            accept (AS3 OR AS4) AND <^AS3+ AS4*$>
   import:  from AS5
            action pref=10;
            accept AS5 AND <^AS5+$> AND community.contains(1:1)
   import:  from AS5
            action pref=0;
            accept AS5 AND <^AS5+$>

   We can see here that basically we are adding identical statements for
   each peering to the policy.  This is the ideal candidate for RPSL's
   refine statement.  This will make the policy more concise and avoid
   some of the potential for errors as more peering statements are added
   in the future:









Meyer, et al.                Informational                     [Page 11]

RFC 2650                 Using RPSL in Practice              August 1999


      aut-num:     AS1
      import: {
                   from AS-ANY
                        action pref=10;
                        accept community.contains(1:1);
                   from AS-ANY
                        action pref=0;
                        accept ANY;
               } refine {
                   from AS2 accept (AS2 OR AS4) AND <^AS2+ AS4*$>;
                   from AS3 accept (AS3 OR AS4) AND <^AS3+ AS4*$>;
                   from AS5 accept AS5 AND <^AS5+$>;
               }

   Now, we can clearly see that any route that has been accepted from a
   customer that contains the community 1:1 will have it's local
   preference value reduced by 10.

   The refinement has cleaned up some of the policy but we still have a
   large number of individual policies representing the same basic
   provider policy "from the customer, accept customer routes".  These
   can be simplified by using AS sets.

   First, we will collect together all of AS1's customers into a single
   AS set, AS1:AS-CUSTOMERS. We use a hierarchical set name that start
   with AS1 to avoid possible set name clashes in IRR with other ASes:

    as-set:      AS1:AS-CUSTOMERS
    members:     AS2, AS3, AS5

   We also define one set for each customer which lists the AS numbers
   of any of their customers.

    as-set:      AS1:AS-CUSTOMERS:AS2
    members:     AS4

    as-set:      AS1:AS-CUSTOMERS:AS3
    members:     AS4

    as-set:      AS1:AS-CUSTOMERS:AS5
    members:     # AS5 has no customers yet, so keep blank for now

   We can now use the keyword PeerAS with these AS sets to simplify the
   policy further:







Meyer, et al.                Informational                     [Page 12]

RFC 2650                 Using RPSL in Practice              August 1999


      aut-num:     AS1
      import: {
                   from AS-ANY
                        action pref=10;
                        accept community.contains(1:1);
                   from AS-ANY
                        action pref=0;
                        accept ANY;
              } refine {
                   from AS1:AS-CUSTOMERS
                        accept (PeerAS OR AS1:AS-CUSTOMER:PeerAS)
                               AND <^PeerAS+ AS1:AS-CUSTOMER:PeerAS*$>
              }

   The use of PeerAS with AS1:AS-CUSTOMERS is basically equivalent to
   looping over the members of AS1:AS-CUSTOMERS, expanding the policy by
   replacing PeerAS with a member from the set AS1:AS-CUSTOMERS.

   To illustrate how this policy might be utilised by AS4, we present
   the following policy fragment:

      aut-num: AS4
      export: to AS2
              action community.append(1:1);
              announce AS1
      export: to AS3
              announce AS1

   Here, AS4 is signalling AS1 to prefer the routes from AS3.

3 Tools

   In this section, we briefly introduce a number of tools which can be
   used to inspect data in the database, to determine optimal routing
   policies, and enter new data.

3.1 The aut-num Object Editor

   All the examples shown in the previous sections may well be edited by
   hand.  They may be extracted one by one from the IRR using the whois
   program, edited, and then handed back to the registry robots.
   However, again the RAToolSet [6] provides a very nice tool which
   makes working with aut-num objects much easier:  the aut-num object
   editor aoe.

   The aut-num object editor has a graphical user interface to view and
   manipulate aut-num objects registered at any IRR. New aut-num objects
   may be generated using templates and submitted to the registries.



Meyer, et al.                Informational                     [Page 13]