Re: issue 11

[Dennis Ferguson <[e-mail]>]

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