here's as far we have got.

farrache at ccpnxt5.in2p3.fr (Gilles Farrache) writes

 * 2) In case of heterogenous aggregation
 * 
 * In the document (page 14) it is stated that teh community SPECIAL may
 * not be relevant to routing, from my point of view that is nonsense. We

It does not say it is not relevant to routing, it says it is an
advisory tag. It cannot be anything else. It has the same status as
as-exclude. 

 * are now dealing with a routing registery not with a global registery,
 * so a community defined in a routing registrery must be relevant to
 * routing !!!! And if this community is relevant to routing the route
 * entry with community SPECIAL must be kept in the registery.
 * 
 * route:  193.0.0.0/20
 * 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
 * 
 * and 
 * 
 * 
 * route:     193.0.9.0/24
 * descr:     Enterprise 2
 * origin:    AS2
 * comm-list: SPECIAL

But Gilles, how do I know what routes are actually being used and what
not? According to the two route objects above, I would expect to see
193.0.9.0/24 in my routing table, where the whole idea is that only
193.0.0.0/20 is routed ...

 * 3) Proxy aggregation
 * 
 * Let's take the example of AS2 making proxy aggregation for AS1. AS1
 * has to be registred in the routing registery in order to be able to
 * define its routing policy with AS2. AS1 is not able to aggregate and
 * ask AS2 to do it for it. AS1 has still to declare all the routes that
 * have to be announced in order to allow AS2 to build access-list or
 * whatever. So the entries for AS1 in the routing registery will be :
 * 
 * route:   193.0.8.0/24
 * origin:  AS1
 * 
 * route:   193.0.9.0/24
 * origin:  AS1
 * 
 * Now in order to aggregate AS2 will generate the following entry:
 * 
 * route:   193.0.8.0/23
 * origin:  AS2
 * descr:   Proxy aggragate for AS1
 * 
 * but the entries of AS1 must not be deleted because they are used
 * between AS1 and AS2. So no component is needded. CQFD.

Again the problem is here that if AS1 has other (non-aggretable)
routes there is no way to specify that the two more specifics are only
relevant to the AS1 and AS2 and are not seen anywhere else. With
components you can tell that these two are not seen specifically, but
are used to make up the aggregate. I agree that components could be
used in the config between AS1 and AS2 to derive the aggregate.

 * 
 * Conclusion :
 * 
 * Components are never needed with the following condition that seems
 * to be evident , a community defined in the routing registery is 
 * 
 * relevant for routing.
 * 
 * (Just a point of detail, in the tool that will show the content
 * of an aggregat hole will take precedence on route. I mean by that
 * that if an aggregat is defined with hole, even if a route equivalent
 * to the hole is present in the registery the hole will be shown)
 * 
 * So now let's take the old attribute ias-int that is used for
 * differents tools. Putting it as a component on a route is not the
 * best solution. In fact it may happend that an interconnect net
 * have not any connectivity outside an AS. An example is easy to
 * find from AS789 to go to AS2156 you cross AS1717, all the
 * interconnections nets on the road are local to AS1717 so 
 * 
 * they are not registred in the routing registry so all the
 * tools are "broken".....

Well that is obvious. If an dmz is not routed there is no way to get
to it, so any tool will not work, even ping or traceroute ... That is
not something specific to a routing registry. 

-Marten





-------- Logged at  Wed May 25 10:39:49 MET DST 1994  ---------