Subject: aggregating with MED and NEXT_HOP

From: "Natale, Jonathan" <[email-masked]>
Date: Wed, 2 Oct 2002 10:57:58 -0400

Folks,

I think this issue got lost.  I thought we had a consensus on 
Changing it to a "MAY", "SHOULD" or some combination.

I propose we remove/or relax:

"Routes that have the following attributes shall not be aggregated
   unless the corresponding attributes of each route are identical:
   MULTI_EXIT_DISC, NEXT_HOP."

Cisco (and I think Juniper as well), does aggregate routes with different
MEDs and NEXT_HOPs, but *I think* Cisco is added, or added, a config switch
for the MED.

Old email thread:

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: Tuesday, September 10, 2002 9:22 PM
To: Natale, Jonathan
Cc: [email-masked]'; [email-masked]
Subject: Re: 

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]
ks.com>, "Natale, Jonathan" writes:
> Currently routes with different meds can be aggregated.  Bug 
> CSCds88309 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

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