Subject: RE:

From: "Natale, Jonathan" <[email-masked]>
Date: Tue, 10 Sep 2002 17:43:38 -0400

Currently routes with different meds can be aggregated.  Bug CSCds88309
requests a switch to stop this.  

Any comments on the NEXT_HOP/aggregate issue?

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: Monday, September 09, 2002 11:37 PM
To: Natale, Jonathan
Cc: [email-masked]
Subject: Re: 

In message
<[email-masked]
ks.com>, "Natale, Jonathan" writes:
> What is the purpose of:
> 
> Routes that have the following attributes shall not be aggregated
>    unless the corresponding attributes of each route are identical:
>    MULTI_EXIT_DISC, NEXT_HOP.
> 
> The major vendor has a bug/request to add a knob to do the MULTI_EXIT_DISC
> part (CSCds88309).  The only reason for the second part I have heard has
to
> do with RPF (can't recall details).  But basically I see no reason for
doing
> either part and I don't think any implementations do either anyway.
> 
> I propose that the reason for these limits be added to the text or remove
> the text altogether.
> 
> Also, is shall not == MUST???

EBGP routes with MULTI_EXIT_DISC can't be aggregated before using the
route or injecting into IBGP since doing so could alter the decision.

Routes with MED can be aggregated before export since the incoming MED
does not affect the value of the outgoing MED (if used the exported
MED is either configured or based on IGP cost).

At worst the AS SET might be affected (in a subtly flawed
inplementation) but with AA being used almost exclusively this is a
complete non-issue (in practice).  If properly implemented the
selection would preceed entry into the RIB and the aggregate formed in
the Adj-Rib_out would be based on those "best routes" in the RIB so
there would be no affect on AS SET.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 10 Sep 2002 21:21:38 -0400

Jonathan,

Your point seems to be that the text could be modified since its under
some conditions it is OK to aggregated MED and NH prior to export.  I
think it may be best if we leave the MED statement alone or only
change it minimally since it can get you into trouble.  Unless I'm
missing something we can probably relax or eliminate the NH statement.
See below for why.

Curtis

ps - sorry for the length of this.

In message <[email-masked]
> requests a switch to stop this.  

I haven't read Cisco's bug report and Cisco behaviour and Cisco bug
reports do not define the spec.  If there is a good reason for the bug
report (like doing so breaks something) then the circumstances and
consequences of the breakage might be of interest to this list.

> Any comments on the NEXT_HOP/aggregate issue?

In both cases, the aggregation should not affect the route decision.

MED is used in local route decisions.  So if EBGP MED is configured to
be ignored, you can get away with aggregation before export into IBGP.
If MED is used just to pick the next hop, then it would be OK to
aggregate then export to IBGP.  In both of these cases, you could get
route decision differences and a route loop if not all routers are
configured the same.  That is why the spec prohibits it.  If EBGP MEDs
and IBGP MEDs are compared, then aggregating before injecting into
IBGP would alter the route decision so don't aggreagate.  The one safe
place to aggregate MED is export to EBGP peers as I indicated below.

With next hop, you can aggregate all you want if you configure
next-hop-self (the "unless" part of case 1 in "5.1.3 NEXT_HOP")
because then the NH are the same.  For EBGP, if you are not doing
third party routes, the NH advertised to the peer are always identical
so you can aggregate.  Both of these cases fall under "its the same so
aggregate".  For what would otherwise be third party EBGP routes, you
could get away with aggregating as long as you didn't mind forwarding
out the same interface to what would have been the third party, and
your peer isn't going to be upset (doesn't have a business reason to
be upset) about you taking a third party route and putting it into an
aggregate, thereby hiding it (can cause unintended, meaning "unpaid
for" transit causing some upset peers at protocol level 8).

There may be no harm done in aggregating different NH together except
for the third party EBGP issue.

Many protocol implementations allow you to just about aggregate
anything before moving the routes into anything else.  That was a goal
of the gated "aggregate" protocol in the config (that was never fully
acheived).  In doing that you provide the user with flexibility but
also the ability to do harmfull things and the ability to violate some
protocol specs.  That doesn't mean the specs should be changed to
reflect that an implementation provides a means to violate it.

In general certain things with BGP can get you into trouble but also
could be done safely if consistently configured and done carefully
enough.  We used to refer to this as "among consenting adults" but
didn't find a good way to word a general "among consenting adults"
exception into the spec.  It was easier to say "don't do that" for
situations that usually got you into trouble.  If we started
enumerating cases in which certain restrictions could be ignored, in
addition to bloating the document, we were also not entirely sure we'd
cover all of the cases and get it exactly right.  Under what
circumstances MED and NEXT_HOP can be aggregated may be one such case
were you could get into trouble and the best thing to say is "don't do
that".

Curtis