rfc1786.txt

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

   Aggregates with Holes

   If we assume that the world of our example still consists of only
   three chunks of address space the aggregate above contains what are
   called holes, parts of an aggregate that are not reachable via the
   originator of the route.  From the routing information itself one
   cannot tell whether these are holes and what part of the route falls
   inside one.  The only way to tell is to send a packet there and see
   whether it gets to the destination, or an ICMP message is received
   back, or there is silence.  On the other hand announcing aggregates
   with holes is quite legitimate.  Consider a 16-bit aggregate with
   only one 24-bit prefix unreachable.  The savings in routing table
   size by far outweigh the hole problem.

   For operational reasons however it is very useful to register these
   holes in the routing registry. Consider the case where a remote
   network operator experiences connectivity problems to addresses



Bates, et al.                                                  [Page 22]

RFC 1786        Representing IP Routing Policies in a RR      March 1995


   inside an aggregate route.  If the packets are getting to the AS
   announcing the aggregate and there are no more specific routes, the
   normal cause of action is to get in touch with the originating AS of
   the aggregate route and ask them to fix the problem. If the address
   falls into a hole this is futile. Therefore problem diagnosis can be
   sped up and unnecessary calls prevented by registering the holes in
   the routing registry. We do this by using the "hole" attribute. In
   our example the representation would be:


   route:       193.0.0.0/20
   descr:       All routes known by AS1
   origin:      AS1
   hole:        193.0.0.0/24
   hole:        193.0.2.0/23
   hole:        193.0.4.0/22
   hole:        193.0.10.0/23
   hole:        193.0.12.0/22
    ...


   Note: there would also be two routes with the withdrawn attribute as
   displayed above (i.e. 193.0.8.0/24 and 193.0.9.0/24).  It is not
   mandatory to document all holes. It is recommended all holes routed
   by another service provider are documented.

   Multiple Proxy Aggregation

   Finally suppose that AS2 decides to announce the same aggregate, as
   in the previous example, they would add the following route object to
   the registry:


   route:       193.0.0.0/20
   descr:       All routes known by AS2
   origin:      AS2
   hole:        193.0.0.0/24
   hole:        193.0.2.0/23
   hole:        193.0.4.0/22
   hole:        193.0.10.0/23
   hole:        193.0.12.0/22
    ...


   Both AS1 and AS2 will be notified that there already is a route to
   the same prefix in the registry.





Bates, et al.                                                  [Page 23]

RFC 1786        Representing IP Routing Policies in a RR      March 1995


   This multiple proxy aggregation is very dangerous to do if the sub-
   aggregates of the route are not the same. It is still dangerous when
   the sub-aggregates are consistent but connectivity to the sub-
   aggregates varies widely between the originators.



   Route object update procedures

   Adding a route object will have to be authorised by the maintainer of
   the originating AS. The actual implementation of this is outside the
   scope of this document.  This guarantees that an AS guardian has full
   control over the registration of the routes it announces [11].


   What is an Inter-AS network ?

   An inter-AS network (Inter-AS IP networks are those networks are
   currently called FIXes, IXFs, DMZs, NAPs, GIX and many other
   acronyms) exists for the purpose of passing traffic and routing
   information between different autonomous systems.  The most simple
   example of an inter-AS network is a point-to-point link, connecting
   exactly two ASes.  Each end of such a link is connected to an
   interface of router belonging to each of the autonomous systems.
   More complex examples are broadcast type networks with multiple
   interfaces connecting multiple ASes with the possibility of more than
   one connection per AS.  Consider the following example of three
   routers 1, 2 and 3 with interfaces a through f  connected by two
   inter-AS networks X and Y:


                              X              Y
                     a1b     ---    c2d     ---    e3f



   Suppose that network X is registered in the routing registry as  part
   of AS1 and net Y as part of AS3. If traffic passes from left to right
   prtraceroute will report the following  sequence  of  interfaces  and
   ASes:

           a in AS1
           c in AS1
           e in AS3


   The traceroute algorithm enumerates only the receiving interfaces on
   the way to the destination.  In the example this leads to the passage



Bates, et al.                                                  [Page 24]

RFC 1786        Representing IP Routing Policies in a RR      March 1995


   of AS2 going unnoticed.  This is confusing to the user and will also
   generate exceptions when the path found is checked against the
   routing registry.


   For operational monitoring tools such as prtraceroute it is necessary
   to know which interface on an inter-AS network belongs to which AS.
   If AS information is not known about interfaces on an inter-AS
   network, tools like prtraceroute cannot determine correctly which
   ASes are being traversed.


   All interfaces on inter-AS networks will are described in a separate
   object know as the `inet-rtr' object [15].





































Bates, et al.                                                  [Page 25]

RFC 1786        Representing IP Routing Policies in a RR      March 1995


6.  The Autonomous System Object


   Autonomous Systems

   An Autonomous System (AS) is a group of IP networks operated by one
   or more network operators which has a single and clearly defined
   external routing policy.

   An AS has a unique number associated with it which is used both in
   exchange of exterior routing information and as an identifier of the
   AS itself.  Exterior routing protocols such as BGP and EGP are used
   to exchange routing information between ASes.

   In routing terms an AS will normally use one or more interior gateway
   protocols (IGPs) in conjunction with some sort of common agreed
   metrics when exchanging network information within its own AS.

   The term AS is often confused or even misused as a convenient way of
   grouping together a set of networks which belong under the same
   administrative umbrella even if within that group of networks there
   are various different routing policies.  We provide the "community"
   concept for such use.  ASes can strictly have only one single
   external routing policy.

   The creation of an AS should be done in a conscious and well
   coordinated manner to avoid creating ASes for the sake of it, perhaps
   resulting in the worst case scenario of one AS per routing
   announcement.  It should be noted that there is a limited number of
   AS numbers available. Also creating an AS may well increase the
   number of AS paths modern EGPs will have to keep track of. This
   aggravates what is known as "the routing table growth problem".  This
   may mean that by applying the general rules for the creation and
   allocation of an AS below, some re-engineering may well be needed.
   However, this may be the only way to actually implement the desired
   routing policy anyway.  The creation and allocation of an AS should
   be done with the following recommendations in mind:


    +   Creation of an AS is only required when exchanging routing
        information with other ASes.  Some router implementations make
        use of an AS number as a form of tagging to identify the routing
        process.  However, it should be noted that this tag does not
        need to be unique unless routing information is indeed exchanged
        with other ASes.






Bates, et al.                                                  [Page 26]

RFC 1786        Representing IP Routing Policies in a RR      March 1995


    +   For a simple case of customer networks connected to a single
        service provider, the IP network should normally be a member of
        the service providers AS. In terms of routing policy the IP
        network has exactly the same policy as the service provider and
        there is no need to make any distinction in routing information.
        This idea may at first seem slightly alien to some, but it
        highlights the clear distinction in the use of the AS number as
        a representation of routing policy as opposed to some form of
        administrative use.


    +   If a network operator connects to more than one AS with
        different routing policies then they need to create their own
        AS.  In the case of multi-homed customer networks connected to
        two service providers there are at least two different routing
        policies to a given customer network.  At this point the
        customer networks will be part of a single AS and this AS would
        be distinct from either of the service providers ASes.  This
        allows the customer the ability of having a different
        representation of policy and preference to the different service
        providers.  This is the ONLY case where a network operator
        should create its own AS number.


    +   As a general rule one should always try to populate the AS with
        as many routes as possible, providing all routes conform to the
        same routing policy.


   Each AS is represented in the RIPE database by both an aut-num object
   and the route objects representing the routes originated by the AS.
   The aut-num object stores descriptive, administrative and contact
   information about the AS as well as the routing policies of the AS in
   relation to all neighboring ASes.

   The origin attributes of the route  objects define the set of routes
   originated by the AS. Each route object can have exactly one origin
   attribute.  Route objects can only be created and updated by the
   maintainer of the AS and not by those immediately responsible for the
   particular routes referenced therein.  This ensures that operators,
   especially service providers, remain in control of AS routing
   announcements.


   The AS object itself is used to represent a description of
   administrative details and the routing policies of the AS itself. The
   AS object definition is depicted as follows.




Bates, et al.                                                  [Page 27]

RFC 1786        Representing IP Routing Policies in a RR      March 1995



   Example:

   aut-num:  AS1104
   descr:    NIKHEF-H Autonomous system
   as-in:    from AS1213 100 accept AS1213
   as-in:    from AS1913 100 accept AS1913
   as-in:    from AS1755 150 accept ANY
   as-out:   to AS1213 announce ANY
   as-out:   to AS1913 announce ANY
   as-out:   to AS1755 announce AS1104 AS1913 AS1213
   tech-c:   Rob Blokzijl
   admin-c:  Eric Wassenaar
   guardian: [e-mail]
   changed:  [e-mail] 920910
   source:   RIPE



   See Appendix A for a complete syntax definition of the "aut-num"
   object.


   It should be noted that this representation provides two things:

       + a set of routes.

       + a description of administrative details and routing policies.

   The set of routes can be used to generate network list based
   configuration information as well as configuration information for
   exterior routing protocols knowing about ASes. This means an AS can
   be defined and is useful even if it does not use routing protocols
   which know about the AS concept.

















Bates, et al.                                                  [Page 28]

RFC 1786        Representing IP Routing Policies in a RR      March 1995


   Description of routing policies between ASs with multiple connections
   - "interas-in/interas-out"

   The following section is only relevant for ASes which use different
   policies on multiple links to the same neighboring AS. Readers not
   doing this may want to skip this section.

   Description of multiple connections between ASs defines how two ASs
   have chosen to set different policies for the use of each or some of
   the connections between the ASs.  This description is necessary only
   if the ASs are connected in more than one way and the routing policy
   and differs at these two connections.



   Example:


                   LINK1
      193.0.1.1 +----------+ 193.0.1.2
                |          |
   AS1------AS2==           ==AS3-----AS4
                |          |
      193.0.1.5 +----------+ 193.0.1.6
                    LINK2



        Note: LINK here denotes the peer connection points between
        ASs.  It is not necessarily just a serial link.  It could
        be ethernet or any other type of connection as well.  It
        can also be a peer session where the address is the same at
        one end and different at the other end.


   It may be that AS2 wants to use LINK2 only for traffic towards AS4.
   LINK1 is used for traffic to AS3 and as backup to AS4, should LINK2
   fail.  To implement this policy, one would use the attribute
   "interas-in" and "interas-out."  This attribute permits ASs to
   describe their local decisions based on its preference such as
   multi-exit-discriminators (MEDs) as used in some inter-domain routing
   protocols (BGP4, IDRP) and to communicate those routing decisions.