Aggregation (was Re: Modification of RIPE-181's as-in/as-out attributes)

Curtis,

Thanks for the clarification. Comments below.

Curtis Villamizar (curtis at ans.net) on November 21:
> 
> In message <199511211858.AA07417 at cat.isi.edu>, Cengiz Alaettinoglu writes:
> > 
> > Sorry for a late reply to this message.
> > 
> > Curtis Villamizar (curtis at ans.net) on October 27:
> > > Add an aggregate-by field and change the holes field in the route
> > > object.  The aggregate-by should have <as-expr> [opts] <route-expr>.
> > > The AS expression is who forms the aggregate (could be an expression,
> > > a macro, whatever).  
> > 
> > Isn't the AS in the origin attribute of the route performing the
> > aggregation? In other words, if a route is aggregated by more than one
> > domain, each would have a route object with their AS number in the
> > origin. So I am not sure if the <as-expr> in the aggregate-by field
> > is useful or not.  
> 
> I was thinking of proxy aggregation where you want to accept
> everything more specific except some holes and then aggregate it.  In
> this case, the origin AS of the more specific prefixes would be
> different from the aggregator.  Maybe there is a better way to do
> this?

In the proxy aggregation case, both the components and the aggregate
needs to be registered. The components would be registered by the
originators using their AS numbers, and aggregate would be registered
by the proxy using the proxy's AS number.	

> 
> > > The route expression is the routes used to form
> > > the aggregate, which might be ThisRoute* (all refines of this route).
> > 
> > The ripe-181 way of specifying the <route-expr> implicitly was: 
> > 	ThisRoute* AND NOT { list of holes }
> > 
> > I think having the components explicitly specified is a good idea.
> 
> If there are holes, you need to know how to route them, not just that
> there are holes.  So having separate route objects for the holes is
> probably a real good idea.  I was proposing (at NANOG) using a
> community to indicate that the AS doing the aggregation must also pass
> the component in order to not screw up routing.
> 
> There also needs to be greater flexibility in choosing what not to
> aggregate.  For example, I may want to form an aggregate and advertise
> it to everyone and some other provider might want to form the same
> aggregate and advertise it to everyone.  We would have to exclude each
> other from the AS set or form an atomic aggregate.  This is also
> rather a problem at the border router.  The two aggregating parties
> need to form an aggregate and announce to each other and accept and
> prefer each other's aggregate.  They also must suppress the two router
> loop (which I think most routers do automatically, at least NSS do).
> 
> Is this a bad idea?  Otherwise, I can't see how ANS and MCI could
> aggregate the customers in Canada that we serve without sending all
> the components routes to each other (as an example).  Maybe that is
> the best we can do, at least helping other providers and hoping a
> third provider will cooperate and allow similar aggregation benefiting
> ANS and MCI or hoping that the technique can be applied elsewhere.
> 
> > > The opt might be [ATOMIC-AGGR] or some other option.  The holes field
> > > needs to specify all the AS that needed components when doing an
> > > aggregation over multiple AS.  It needs an optiona <as-expr>.  The
> > > holes field should allow a route expression rather than just a single
> > > route.  The holes field would the be <route-expr> or <as-expr>
> > > <route-expr>.  If the AS expression is omitted it means the hole needs
> > > to be routed to the entire world to get routing right.
> > 
> > I think you are assigning new semantics to the holes field. If X has
> > 128/8 and Y has 129/8 and if they decide to form an aggregate 128/7,
> > you need the components to be routed in X and Y even though the
> > aggregate have no holes. Is this what you are trying to document in
> > this field?
> 
> Actually, I think I have sematics in mind that are not really
> supported yet and I'm looking for ways to express them.
> 
> > > The aggregate-by can be used to configure aggregation.  The holes can
> > > be used to control full leak of components for multiprovider
> > > aggregation.  The holes should be specified reliably enough that
> > > export policy of a router can block more specifics of any aggregate.
> > > It would be a real nice thing if we could specify:
> > > 
> > >   route: xxx/8
> > >   aggregate-by: EUROPEANS { xxx/8* }
> > >   holes: EUROPEANS { xxx/8* }
> > > 
> > >   route: yyy/8
> > >   aggregate-by: NORTHAMERICANS { yyy/8* }
> > >   holes: NORTHAMERICANS { yyy/8* }
> > > 
> > > And have the export (and import) on the routers determined by whether
> > > the target AS is in the AS-MACRO.  More likely expressions with one or
> > > two AS or a small AS-MACRO would appear in the nearterm.
> > 
> > Let me see. You want the route object to specify import and export
> > policies of domains (looks like advisories to me). I would be more
> > comfortable if we defined some operators/functions and specify import
> > and export policies using these operators/functions.
> 
> No this is aggregation.  If it crosses provider boundaries, then it
> needs to be in the route object.  If AS690 forms an aggregate and has
> origin AS 690 on the aggregate, then AS690 controls the scope of the
> aggregate.  I've proposed we do this by convention by setting some
> communities.  I'd rather the route object had explicit support rather
> than us relying on communities and conventions.
> 
> If I change aggregation, I don't want to edit every as-out line to
> reflect the new policy.  I'd rather express it in terms of special
> communities and tag the aggregates and components with the community
> names.  Part of what I've been suggesting (in nanog) is specially
> named communities and usage conventions.
> 
> > For example, lets define a function holes_of(<as-no>) which returns
> > the route expressions of the holes attributes where the as-no
> > appears. Then, 
> > 
> > 	as-out: to ASfoo announce holes_of(ASfoo)
> > 
> > would do. The advantage of this is that the route object does not
> > specify how that route is imported/exported, yet the information that
> > is available there can be used at the discretion of a domain.
> 
> How about:
> 
>   as-out: to ASfoo announce myAS and not holes_of(myAS)
> 

fine.

> The way I'm coding it (using communities), it comes out looking more:
> 
>   as-out: to ASfoo announce ALL and not ( MyAggr* and not MyComp )
> 
> This may not be all that clear.  The intention is announce everything
> except block components of aggregates, but don't block specific
> components (dual homed sites or other holes).
> 
> One problem with the holes is that there are two separate things we
> need to express:
> 
>   what gets left out when forming the aggregate
>   what gets explicitly announced even though it overlaps the aggregate

OK. Let say there are four components, one of them is originated by
ANS x/24, 2 by MCI y/24 & z/24 and 1 not allocated w/24 (a true
hole). Lets assume the aggregate is v/22. Hence the following route
objects: 

route: x/24
origin: AS690

route: y/24
origin: AS3561

route: z/24
origin: AS3561

route: v/22
origin: AS690
holes: {w/24}                         
component: {x/24} exhange-within AS-expr1 # AS expr specifies which AS's
				          # need these components
component: {y/24, z/24} exhange-within AS-expr2

route: v/22
origin: AS3561
holes: {w/24}                         
component: {y/24, z/24} exhange-within AS-expr3          
component: {x/24} exhange-within AS-expr4          


If AS-expr always and only contains the AS's that originate the
components then we do not need the component attribute since a
database lookup can tell us this information. But I suppose if ANS
and MCI are not direct neighbors, or for efficiency, the AS-expr may
need to include other transit AS's.

Both holes and component attributes may specify route list returning
expressions, e.g.
	component: {v/22}* AND AS3561 exhange-within AS690 AS3561 
If there is a component which is not covered by a component attribute 
the AS-expr for it is NOT ANY (i.e. that component is not announced
any where). 

>From these objects, one can generate configs (aggregate v/22* AND NOT
{w/24}, and appropriate as-out lines using some functions of these
route objects like holes_of or components_of, etc).

The route object definition is backward compatible with Ripe181.

What do you think? Lets further discuss this at IETF.

> 
> These can be two different sets.  
> 
> > What do you think?
> 
> I think we can live with using communities to do what we want to do
> except maybe blocking specific things from the aggregation.  There we
> may need to block based on AS paths (for example, don't aggregate
> anything with MCI in it if you know it overlaps some MCI stuff and you
> will need to send the aggregate to MCI).
> 
> > Cengiz
> 
> Curtis


Cengiz

-- 
Cengiz Alaettinoglu       Information Sciences Institute
(310) 822-1511            University of Southern California
http://www.isi.edu/div7/people/cengiz