Subject: RE: issue 11

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 2 Oct 2002 10:17:26 -0400

Dennis:
  The assumption I made is AS-SET is not used at the aggregation point.

Sorry, if I misled you on the first part. 

Thanks,
Ben

> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[email-masked]]
> Sent: Wednesday, October 02, 2002 10:06 AM
> To: 'Dennis Ferguson'; Dimitry Haskin
> Cc: 'Natale, Jonathan'; [email-masked]
> Subject: RE: issue 11 
> 
> 
> Dennis:
> 
>   The potential weakness to aggregation when AS-PATH list of component
> routes
> are left out of the aggregated route is that the downstream peers that
> receive
> the aggregate route have no knowledge of the real path taken 
> from their
> point to the origin of any component route and thus are 
> unable to gaurantee
> loop free routing from their point to any component route's 
> destination. 
> 
> In the multi-path scenario, if we aggregate two, same prefix, 
> different
> AS-PATHS, different Next Hop, routes into one aggregate route 
> we hit this
> weakness. Do you agree?
> 
> My instinct is only to use multi-path in a localized manor, 
> load balance
> between two interfaces from one router to another, if we must 
> load balance
> between two interfaces to two separate routers, limit the amount of
> divergence these routes define in their AS_PATH attributes. 
> Perhaps have 1
> router setup to multipath to 2 other routers in the same AS 
> whose AS_PATH
> entries are the same. Once we start diverging, we get into 
> all kinds of
> permutations on the AS_PATH issue, we have to use aggregation 
> or we have to
> perform more policy decisions on how to deal with this, etc.
> 
> Since BGP4 does not provide the ability to tell another peer 
> that two routes
> which have the same prefix and different attributes are to be 
> treated as
> multipath routes, we are stuck with information that is 
> advertised to peers
> that is suboptimal.  Perhaps this feature, should be added to 
> a new draft
> titled "BGP Multipath" that you can edit, since you have vast 
> knowledge on
> the subject.
> 
> 
> Regards,
> Ben
> 
> > -----Original Message-----
> > From: Dennis Ferguson [mailto:[email-masked]]
> > Sent: Tuesday, October 01, 2002 11:20 PM
> > To: Dimitry Haskin
> > Cc: 'Natale, Jonathan'; [email-masked]
> > Subject: Re: issue 11 
> > 
> > 
> > Dimitry,
> > 
> > > After all if a BGP speaker chooses to advertise a single 
> > route even when
> > > multiple component routes are used for local forwarding, 
> > this in effect
> > > constitutes an aggregation -- even if the aggregate and 
> > components have
> > > the same prefix. As such, it should comply with aggregation 
> > rules that
> > > have been defined to provide loop-free routing.
> > 
> > I think the problem with this is the assertion that the 
> rules defined
> > in the document for AS path aggregation (I'm looking at the 
> > -17 document)
> > are necessary to provide loop-free routing in any case other 
> > than yours.
> > Obtaining loop-free routing does not require combining AS 
> paths in any
> > current situation, and because of this most routers, and 
> most users of
> > routers, don't always do route aggregation as defined in 
> the document.
> > 
> > In particular, if the aggregation is strictly mask-narrowing, 
> > that is all
> > component routes of the aggregate have a more specific 
> prefix than the
> > aggregate, then loop-free routing is guaranteed even if all 
> > the AS paths in
> > the component routes are ignored and we just reset the 
> > aggregate route's
> > AS path to nothing (you used to have to throw 
> > ATOMIC_AGGREGATE in there to
> > make this strictly correct, but I understand even this is 
> > being deprecated).
> > Doing the fancier thing may provide useful policy information 
> > for downstream
> > route recipients, but providing or not providing that 
> > information is a choice
> > for the aggregator which has no effect on the correctness of 
> > the protocol.
> > Because of this most routers have a knob which tells them to 
> > not bother
> > with the fancy aggregation of AS path information at all, and 
> > in fact many
> > users get this done while avoiding any command mentioning 
> > "aggregate" by
> > doing the same thing solely with readvertisement policy, 
> creating the
> > aggregate route as a static with reject next hop and 
> > readvertising this
> > while suppressing readvertisement of the matching 
> > more-specifics.  None
> > of this really conforms to the AS path aggregation rules in the
> > specification, but all of it produces loop-free routing anyway.
> > 
> > The exception to this occurs when one (or more) of the routes being
> > aggregated is a prefix match for the aggregate route.  While you can
> > still ignore the AS paths on more specific routes in this 
> > case, guaranteeing
> > loop freedom demands that the aggregate AS path include all 
> > the AS numbers
> > in the path(s) of the matching prefix(es).  Currently, 
> however, there
> > is never more than one component route which is a prefix match for
> > the aggregate, so for loop-free routing it is sufficient to 
> advertise
> > the aggregate with the AS path of that route alone.  You can do this
> > solely with redistribution policy as well (readvertise the 
> route which
> > is a prefix match, but suppress all the more-specifics), so 
> > again it is
> > unnecessary to actually combine AS paths from multiple 
> routes for any
> > loop-avoidance purposes.
> > 
> > > I don't mind if the multi-path issues are kept out of the 
> > document. But
> > > if there is insistence to provide some guidance, I hoped 
> > that a general
> > > conceptual statement could be sufficient.
> > 
> > What you describe is a reasonable way to do this function, 
> but I think
> > the fact that it actually depends on the combination of 
> > component route
> > AS paths into the aggregate route's AS path for the purpose 
> > of ensuring
> > correct, loop-free routing, and that it can't be safely 
> > simulated by simple
> > redistribution policy, makes it unique enough to require more 
> > explanation
> > than just a conceptual statement.
> > 
> > Dennis Ferguson
> > 
>