rfc2650.txt

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

   about your internal routing specifics.  Therefore, external routes
   are in general aggregated combinations of internal routes, having
   shorter IP prefixes where applicable according to the CIDR rules.
   Please see the CIDR FAQ [5] for a tutorial introduction to CIDR. It
   is strongly recommended that you aggregate your routes as much as
   possible, thereby minimizing the number of routes you inject into the
   global routing table and at the same time reducing the corresponding
   number of route objects in the IRR.

   While you may easily query single route objects using the whois
   program, and submit objects via mail to the registry robots, this
   becomes kind of awkward for larger sets.  The RAToolSet [6] offers
   several tools to make handling of route objects easier.  If you want
   to read policy data from the IRR and process it by other programs,
   you might be interested in using peval which is a low level policy
   evaluation tool.  As an example, the command

      peval -h whois.ra.net AS3582

   will give you all route objects from AS3582 registered with RADB.






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


   A much more sophisticated tool from the RAToolSet to handle route
   objects interactively is the route object editor roe.  It has a
   graphical user interface to view and manipulate route objects
   registered at any IRR. New route objects may be generated from
   templates and submitted to the registries.  Moreover, the route
   objects from the databases may be compared to real life routes.
   Therefore, roe is highly recommended as an interface to the IRR for
   route objects.  Further information on peval and roe is available
   together with the RAToolSet [6].

A.4 Set Objects

   With routing policies it is often necessary to reference groups of
   autonomous systems or routes which have identical properties
   regarding a specific policy.  To make working with such groups easier
   RPSL allows to combine them in set objects.  There are two basic
   types of predefined set objects, as-set, and route-set.  The RPSL set
   objects are described below.

A.4.1 AS-SET Object

   Autonomous system set objects (as-set) are used to group autonomous
   system objects into named sets.  An as-set has an RPSL name that
   starts with "AS-".  In the example in Figure 17, an as-set called
   AS-NERO-PARTNERS and containing AS3701, AS4201, AS3582, AS4222,
   AS1798 is defined.  The as-set is the RPSL replacement for the RIPE-
   181 as-macro.  It has been extended to include ASes in the set
   indirectly by referencing as set names in the aut-num objects.

   AS-SETs are particularly useful when specifying policies for groups
   such as customers, providers, or for transit.  You are encouraged to
   register sets for these groups because it is most likely that you
   will treat them alike, i.e. you will have a very similar routing
   policy for all your customers which have an autonomous system of
   their own.  You may as well discover that this is also true for the
   providers you are peering with, and it is most convenient to have the
   ASes combined in one as-set for which you offer transit.  For
   example, if a transit provider specifies its import policy using its
   customer's as-set (i.e., its import clause for the customer contains
   the customer's as-set), then that customer can modify the set of ASes
   that its transit provider accepts from it.  Again, this can be
   accomplished without requiring the customer or the transit provider
   to modify its aut-num object.

      as-set:    AS3582:AS-PARTNERS
      members:   AS3701, AS4201, AS3582, AS4222, AS1798

                          Figure 17:  as-set Object



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


   The ASes of the set are simply compiled in a comma delimited list
   following the members attribute of the as-set.  This list may also
   contain other AS-SET names.

A.4.2 ROUTE-SET Object

   A route-set is a way to name a group of routes.  The syntax is
   similar to the as-set.  A route-set has an RPSL name that starts with
   "RS-".  The members attribute lists the members of the set.  The
   value of a members attribute is a list of address prefixes, or
   route-set names.  The members of the route-set are the address
   prefixes or the names of other route sets specified.

   Figure 18 presents some example route-set objects.  The set rs-uo
   contains two address prefixes, namely 128.223.0.0/16 and
   198.32.162.0/24.  The set rs-bar contains the members of the set rs-
   uo and the address prefix 128.7.0.0/16.  The set rs-martians
   illustrate the use of range operators.  0.0.0.0/0^32 are the length
   32 more specifics of 0.0.0.0/0, i.e. the host routes; 224.0.0.0/3^+
   are the more specifics of 224.0.0.0/3, i.e. the routes falling into
   the multicast address space.  For more complete list of range
   operators please refer to RFC-2622.

      route-set: rs-uo
      members: 128.223.0.0/16, 198.32.162.0/24

      route-set: rs-bar
      members: 128.7.0.0/16, rs-uo

      route-set: rs-martians
      remarks: routes not accepted from any peer
      members: 0.0.0.0/0,              # default route
               0.0.0.0/0^32,           # host routes
               224.0.0.0/3^+,          # multicast routes
               127.0.0.0/8^9-32, . . .

                        Figure 18:  route-set Objects














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


B Output of RtConfig:  An Example

      In Figure 19, you see the result of running RtConfig on the source
      file in Figure 11.

      router    bgp 3582
      network   128.223.0.0
      !
      !       NERO
      neighbor 198.32.162.2 remote-as 3701

      no access-list 100
      access-list 100 permit ip 128.223.0.0   0.0.0.0   255.255.0.0   0.0.0.0
      access-list 100 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
      !
      no route-map AS3701-EXPORT
      route-map AS3701-EXPORT permit 1
       match ip address 100
      !
      router bgp 3582
      neighbor 198.32.162.2 route-map AS3701-EXPORT out
      !
      no route-map AS3701-IMPORT
      route-map AS3701-IMPORT permit 1
       set local-preference 1000
      !
      router bgp 3582
      neighbor 198.32.162.2 route-map AS3701-IMPORT in
      !
      !       WNA/VERIO
      neighbor 198.32.162.6 remote-as 2914
      !
      no route-map AS2914-EXPORT
      route-map AS2914-EXPORT permit 1
       match ip address 100
      !
      router bgp 3582
      neighbor 198.32.162.6 route-map AS2914-EXPORT out
      no ip as-path access-list  100
      ip as-path access-list 100 permit ^_2914(((_[0-9]+))*_             \
            (13|22|97|132|175|668|1914|2905|2914|3361|3381|3791|3937|    \
             4178|4354|4571|4674|4683|5091|5303|5798|5855|5856|5881|6083 \
             |6188|6971|7790|7951|8028))?$
      !
      no route-map AS2914-IMPORT
      route-map AS2914-IMPORT permit 1
       match as-path 100
       set local-preference 998



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


      !
      router bgp 3582
      neighbor 198.32.162.6 route-map AS2914-IMPORT in

                        Figure 19:  Output of RtConfig


Security Considerations

      This document is a tutorial to RPSL, it does not define protocols or
      standards that need to be secured.

Endnotes

   (1) AS-PATH regular expressions are POSIX compliant regular
       expressions.

   (2) Discussion of RtConfig internals is beyond the scope of this
       document.

   (3) Clearly, neither of these mechanisms is sufficient to provide
       strong authentication or authorization.  Other public key (e.g.,
       PGP) authentication mechanisms are available from some of the
       IRRs.

References

   [1] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer,
       D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing Policy
       Specification Language (RPSL)", RFC 2622, June 1999.

   [2] Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P. and M.
       Terpstra, "Representation of IP Routing Policies in the RIPE
       database", Technical Report ripe-81, RIPE, RIPE NCC, Amsterdam,
       Netherlands, February 1993.

   [3] T. Bates, E. Gerich, J. Joncharay, J-M. Jouanigot, D. Karrenberg,
       M.  Terpstra, and J. Yu. Representation of IP Routing Policies in
       a Routing Registry, Technical Report ripe-181, RIPE, RIPE NCC,
       Amsterdam, Netherlands, October 1994.

   [4] A. M. R. Magee. RIPE NCC Database Documentation. Technical Report
       RIPE-157, RIPE NCC, Amsterdam, Netherlands, May 1997.

   [5] Hank Nussbacher. The CIDR FAQ. Tel Aviv University and IBM
       Israel.  http://www.ibm.net.il/~hank/cidr.html

   [6] The RAToolSet. http://www.ra.net/ra/RAToolSet/



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


   [7] Rekhter Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC
       1654, July 1994.

   [8] RtConfig as part of the RAToolSet.
       http://www.ra.net/ra/RAToolSet/RtConfig.html

   [9] Chen, E. and T. Bates, "An Application of the BGP Community
       Attribute in Multi-Home Routing", RFC 1998, August 1996.

Authors' Addresses

   David Meyer
   Cisco Systems

   EMail: [e-mail]


   Joachim Schmitz
   America On-Line

   EMail: [e-mail]


   Carol Orange
   RIPE NCC

   EMail: [e-mail]


   Mark Prior
   connect.com.au pty ltd

   EMail: [e-mail]


   Cengiz Alaettinoglu
   USC/Information Sciences Institute

   EMail: [e-mail]












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


Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Meyer, et al.                Informational                     [Page 26]