Subject: RE: Aggregation and MULTI_EXIT_DISC, NEXT_HOP

From: "Natale, Jonathan" <[email-masked]>
Date: Tue, 9 Jul 2002 10:48:04 -0400

I raised this issue more than two years ago.  What is the story on bgp?  Why
is the draft/rfc so far off base?  I would be happy to provide a laundry
list of things, if that will help.

I think the MED was fixed in a major vendor's code with the ~= deterministic
med cmd (or so I was told then, but now the story on that cmd seem
different).

The next hop was never "fixed".  The only answer for why not to aggregate if
nxhp not the same was that it has something to do w/ mcast RPF... but I
never fully digested this.

-$0.02

-----Original Message-----
From: Fryczke, Pawel [mailto:[email-masked]] 
Sent: Thursday, July 04, 2002 8:08 AM
To: [email-masked]
Subject: Aggregation and MULTI_EXIT_DISC, NEXT_HOP

The latest draft, draft-ietf-idr-bgp4-17.txt states:
Routes that have the following attributes shall not be aggregated
unless the corresponding attributes of each route are identical:
MULTI_EXIT_DISC, NEXT_HOP.

Many vendors (e.g. Cisco/Juniper) does not follow this requirement. Why?
What is the purpose of this requirement?
Pawel

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 9 Jul 2002 12:30:31 -0400

> list of things, if that will help.

That list would be good.  At the very least, it lets us adjust the
spec to "should" versus "shall" if we decide that it makes sense to
do so.

> med cmd (or so I was told then, but now the story on that cmd seem

deterministic med fixes the MED election to follow the spec.  I
don't believe it has anything to do with aggregation.

> never fully digested this.

Once Upon a Time (-12?) the active route was "echoed" back to
the external peer which it was learned from to facilitate multicast
RPF checks.  No one appeared to use this, so it was removed from the
spec.  If the only reason for the nexthop to be the same in aggregation
was for a similar reason, it may be worth removing the restriction.

-- 
Jeff Haas 
NextHop Technologies