Subject: RE: issue 11

From: "Natale, Jonathan" <[email-masked]>
Date: Tue, 1 Oct 2002 08:56:07 -0400

I disagree, this does not reflect current implementations that I know of.
Does anybody's implementation do this? 

-----Original Message-----
From: Dimitry Haskin [mailto:[email-masked]] 
Sent: Monday, September 30, 2002 6:39 PM
To: 'Alex Zinin'; Yakov Rekhter
Cc: [email-masked]
Subject: RE: issue 11

The following paragraph somewhere in the document may help resolve the
issue:

"If more than a single BGP route to the same destination prefix are
selected to be used locally by a speaker (e.g. for the load sharing
purposes), such a BGP speaker SHOULD form an aggregate of all such routes
for the purpose of advertising this prefix to other BGP peers. Route
aggregation rules are specified in section 9.2.2.2."

Dimitry

> -----Original Message-----
> From: Alex Zinin [mailto:[email-masked]]
> Sent: Monday, September 30, 2002 2:21 PM
> To: Yakov Rekhter
> Cc: [email-masked]
> Subject: Re: issue 11
> 
> 
> Yakov,
> 
> [...]
> >>    Multipath is
> >>   something that is normally in the heart of a routing 
> protocol. There
> >>   should be a good reason to want something like this in a separate
> >>   document. Do we have one in this case?
> 
> > Time. If we are interested in getting the base spec completed within
> > the timeframe outlined in the current charter, we can't add
> > substantial new material to the spec. 
> 
> I share the concern about time. However, the issues related to best
> path calculation, multipath included, seem to me to be quite important
> from the perspective of interoperability and description of further
> extensions. Maybe if we the chairs could get the right people together
> and facilitate the process (ADs would definitely contribute to buying
> the libations), such a design team could come up with solid stuff
> within a month?
> 
> BTW, regarding the part of the spec describing the best path selection
> algo, I remember there was a concern that it didn't really describe
> what vendors actually did. Is it still the case?
> 
> Alex
> 
>

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 01 Oct 2002 07:48:30 -0700

Jonathan,

> I disagree, this does not reflect current implementations that I know of.

How do implementations that you know of handle this ?

yakov.

---

From: "Dimitry Haskin" <[email-masked]>
Date: Tue, 1 Oct 2002 12:05:35 -0400

As far as I aware, this is what has been effectively implemented when
multiple E-BGP routes to the same prefix are used for load balancing. To
be precise, as far as I know, those implementations restrict multi-path
eligibility to peers in the same neighboring AS so that routes may only
differ in the next hop attribute. Hence, in this restricted case the
aggregate would look exactly the same as components except that if
components differ in the next-hop attribute, the aggregate route should
be advertised with the local address of the speaker.

The proposed paragraph tries to be more general in its guidance for
multi-path use and to extend to the cases when routes to different ASs
are used for multi-path forwarding.

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 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.

Regards,
 Dimitry

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Natale, Jonathan
> Sent: Tuesday, October 01, 2002 8:56 AM
> To: [email-masked]
> Subject: RE: issue 11
>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Oct 2002 12:13:12 -0400

On Tue, Oct 01, 2002 at 12:05:35PM -0400, Dimitry Haskin wrote:
> differ in the next hop attribute.

If router A peers with router X and Y in a neighboring AS, then it
is quite possible for a given prefix D to have two completely
different sets of path attributes.

At the very least, the AS_PATH may differ and thus the loop
properties will differ as well.  If you don't advertise an aggregated
AS_PATH (as one suggestion made), then you can do Bad Things.
If you make sure that at the very least the AS_PATHs are equivalent,
then thats at least one problem thats dealt with.

> Hence, in this restricted case the
> components differ in the next-hop attribute,

That'd work.

> the aggregate route should

And that too.

> conceptual statement could be sufficient.

IMO, its best if we just left the issue of multi-path forwarding out
of the base spec as black magic.  We can publish the Necronomicon later.

-- 
Jeff Haas 
NextHop Technologies

---

From: Alex Zinin <[email-masked]>
Date: Tue, 1 Oct 2002 09:37:27 -0700

Besides, it doesn't say anything about how the routes
are selected.

-- 
Alex

---

From: Dennis Ferguson <[email-masked]>
Date: Tue, 01 Oct 2002 20:19:50 -0700

Dimitry,

> 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.

> 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