rfc1786.txt

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

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


5.  The Route Object

   As stated in the previous chapter routing and address space
   allocation information are now clearly separated.  This is performed
   with the introduction of the route object. The route object will
   contain all the information regarding a routing announcement.

   All routing related attributes are removed from the inetnum object.
   Some old attributes are obsoleted: connect, routpr-l, bdryg-l, nsf-
   in, nsf-out, gateway).  The currently useful routing attributes are
   moved to the route object: aut-sys becomes origin, ias-int will be
   encoded as part of the inet-rtr [15] object and comm-list simply
   moves.  See [6] for detail of the "inetnum" object definition.


   The information in the old inetnum object

   inetnum:   192.87.45.0
   netname:   RIPE-NCC
   descr:     RIPE Network Coordination Centre
   descr:     Amsterdam, Netherlands
   country:   NL
   admin-c:   Daniel Karrenberg
   tech-c:    Marten Terpstra
   connect:   RIPE NSF WCW
   aut-sys:   AS3333
   comm-list: SURFNET
   ias-int:   192.87.45.80  AS1104
   ias-int:   192.87.45.6   AS2122
   ias-int:   192.87.45.254 AS2600
   rev-srv:   ns.ripe.net
   rev-srv:   ns.eu.net
   notify:    [e-mail]
   changed:   [e-mail] 940110
   source:    RIPE


   will be distributed over two objects:













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



   inetnum:   192.87.45.0
   netname:   RIPE-NCC
   descr:     RIPE Network Coordination Centre
   descr:     Amsterdam, Netherlands
   country:   NL
   admin-c:   Daniel Karrenberg
   tech-c:    Marten Terpstra
   rev-srv:   ns.ripe.net
   rev-srv:   ns.eu.net
   notify:    [e-mail]
   changed:   [e-mail] 940110
   source:    RIPE

   route:       192.87.45.0/24
   descr:       RIPE Network Coordination Centre
   origin:      AS3333
   comm-list:   SURFNET
   changed:     [e-mail] 940427
   source:      RIPE



   The route object is used to represent a single route originated into
   the Internet routing mesh.  The actual syntax is given in Appendix D.
   However, there are several important aspects of the attributes worthy
   of note.


   The value of the route attribute will be a classless address.  It
   represents the exact route being injected into the routing mesh.  The
   representation of classless addresses is described in [10].


   The value of the origin attribute will be an AS reference of the form
   AS1234 referring to an aut-num object.  It represents the AS
   injecting this route into the routing mesh.  The "aut-num" object
   (see below) thus referenced provides all the contact information for
   this route.


   Special cases: There can only be a single originating AS in each
   route object.  However in todays Internet sometimes a route is
   injected by more than one AS. This situation is potentially dangerous
   as it can create conflicting routing policies for that route and
   requires coordination between the originating ASes.  In the routing
   registry this is represented by multiple route objects.




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


   This is a departure from the one route (net), one AS principle of the
   ripe-81 routing registry. The consequences for the different tools
   based in the routing registry will need to be evaluated and possibly
   additional consistency checking of the database is needed.


   The examples below will illustrate the usage of the route object
   further.  Suppose three chunks of address space of 2 different
   enterprises represented by the following inetnum objects:


   Examples


   inetnum:   193.0.1.0
   netname:   ENT-1
   descr:     Enterprise 1
    ...

   inetnum:   193.0.8.0
   netname:   ENT-2
   descr:     Enterprise 2
    ...

   inetnum:   193.0.9.0
   netname:   ENT-2-SPEC
   descr:     Enterprise 2
    ...


   Supposing that the Enterprises have their own AS numbers straight
   application of routing without aggregation would yield:


   route:       193.0.1.0/24
   descr:       Enterprise 1
   origin:      AS1
    ...

   route:       193.0.8.0/24
   descr:       Enterprise 2
   origin:      AS2
    ...

   route:       193.0.9.0/24
   descr:       Enterprise 2
   origin:      AS2
    ...



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


   NB: This representation can be achieved by straight translation from
   the ripe-81 representation. See Appendix G for more details.


   Homogeneous Aggregation

   The two chunks of address space of Enterprise 2 can be represented by
   one aggregate route turning two route objects into one and
   potentially saving routing table space for one route.


   route:       193.0.8.0/23
   descr:       Enterprise 2
   origin:      AS2
    ...


   Note that AS2 can also decide to originate all routes mentioned so
   far, two 24-bit prefixes and one 23-bit prefix. This case would be
   represented by storing all three route objects in the database. In
   this particular example the additional routes will not add any
   functionality however and only increase the amount of routes
   announced unnecessarily.


   Heterogeneous Aggregation

   Consider the following case however:


   route:       193.0.8.0/24
   descr:       Enterprise 2
   origin:      AS2
    ...

   route:       193.0.9.0/24
   descr:       Enterprise 2 / Special
   origin:      AS2
   comm-list:   SPECIAL
    ...


   Now the prefix 193.0.9.0/24 belongs to community SPECIAL (this
   community may well not be relevant to routing) and the other prefix
   originated by AS2 does not. If AS2 aggregates these prefixes into the
   193.0.8.0/23 prefix, routing policies based on the community value
   SPECIAL cannot be implemented in general, because there is no way to
   distinguish between the special and the not-so-special parts of AS2.



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


   If another AS has the policy to accept only routes to members of
   community SPECIAL it cannot implement it, because accepting the route
   to 193.0.8.0/23 would also route to 193.0.8.0/24 and not accepting
   this route would lose connectivity to the special part 193.0.9.0/24.
   We call aggregate routes consisting of components belonging to
   different communities or even different ASes "heterogeneous
   aggregates".

   The major problem introduced with heterogeneous aggregates is that
   once the homogeneous more specific routes are withdrawn one cannot
   tell if a more specific part of the heterogeneous route has a
   different policy. However, it can be counter argued that knowing this
   policy is of little use since a routing policy based on the less
   specific heterogeneous aggregate only cannot be implemented. In fact,
   this displays a facet of CIDR itself in that one may actually trade
   off implementing slight policy variations over announcing a larger
   (albeit heterogeneous in terms of policy) aggregate to save routing
   table space.

   However, it is still useful to be able to document these variations
   in policy especially when this homogeneous more specific route is
   just being withdrawn. For this one can use the "withdrawn" attribute.
   The withdrawn attribute can serve to both indicate that a less
   specific aggregate is in fact heterogeneous and also allow the
   general documenting of route withdrawal.

   So there has to be a way for AS2 to document this even if it does not
   originate the route to 193.0.9.0/24 any more.  This can be done with
   the "withdrawn" attribute of the route object.  The aggregate route
   to 193.0.8.0/23 is now be registered as:


   route:       193.0.8.0/23
   descr:       Enterprise 2
   origin:      AS2
    ...


   With the two homogeneous routes marked as withdrawn from the Internet
   routing mesh but still preserving their original routing information.











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



   route:       193.0.8.0/24
   descr:       Enterprise 2
   origin:      AS2
   withdrawn:   940701
    ...

   route:       193.0.9.0/24
   descr:       Enterprise 2 / Special
   origin:      AS2
   comm-list:   SPECIAL
   withdrawn:   940701
    ...


   It should be noted that the date value used in the withdrawn
   attribute can only be in the past.


   Proxy Aggregation

   The next step of aggregation are aggregates consisting of more than
   one AS. This generally means one AS is aggregating on behalf of
   another. It is called proxy aggregation. Proxy aggregation should be
   done with great care and always be coordinated with other providers
   announcing the same route.

   Consider the following:


   route:       193.0.0.0/20
   descr:       All routes known by AS1 in a single package
   origin:      AS1
    ...



   route:       193.0.1.0/24
   descr:       Foo
   origin:      AS1
   withdrawn:   940310
    ...









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



   route:       193.0.8.0/24
   descr:       Bar
   origin:      AS2
   withdrawn:   940310
    ...



   route:       193.0.9.0/24
   descr:       Bar-2
   origin:      AS2
   withdrawn:   940310
   comm-list:   SPECIAL
    ...





   If AS1 announced no other routes to a single homed neighboring AS,
   that neighbor can in general either take that route or leave it but
   not differentiate between AS1 and AS2.

   Note: If the neighbor was previously configured to accept routes
   originating in AS2 but not in AS1 they lose connectivity to AS2 as
   well.  This means that proxy aggregation has to be done carefully and
   in a well coordinated fashion. The information in the withdrawn route
   object can help to achieve that.