Subject: RE: issue 11

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

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
>