Subject: Aggregation and MED on the issues list

From: "Mireille Shammas" <[email-masked]>
Date: 14 Jan 2003 09:15:05 -0500

Hi,
A while back when draft-18 was being reviewed an issue was raised
regarding section 9.2.2.2

"Routes that have different MULTI_EXIT_DISC attribute SHALL NOT be
aggregated."

This issue was not tracked down by issues list.

Many people have argued that this rule could be relaxed to SHOULD NOT
since many venders don't comply. I understand that this can be harmful
in some situations. However,  The correct behavior for aggregating
routes with the same MED was never clarified. For example, what is
correct behavior if we have 4 prefixes contributing to an aggregate
address and 2 of them have MED x and the other 2 have MED y. Should we
aggregate at all in this situations?

I think this issue needs to be added to the list to get its full
diligence.

Mireille

---

From: [email-masked]
Date: Thu, 16 Jan 2003 13:35:13 -0800

Mireille,

I thought this issue was addressed in issue 65 from the v1.x lists.  I've
included the issue listing below.

Andrew

> I think this issue needs to be added to the list to get its full

----------------------------------------------------------------------------
65) Rules for Aggregating with MED and NEXT_HOP
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Clear up the text on aggregating with a MED.  See the discussion
for the text.

Discussion:

There is a proposal to relax this statement:

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

In his reply to the original mail, Curtis asserted that we should leave
the MED rules alone, but perhaps we could relax the NEXT_HOP statement.

This was revisited in the "aggregating with MED and NEXT_HOP" thread.

Yakov suggested we replace:

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

If the aggregation occurs as part of the update process, routes with
different NEXT_HOP values can be aggregated when announced through an
external BGP session.

Path attributes that have different type codes can not be aggregated
together. Path attributes of the same type code may be aggregated,
according to the following rules:

with:

Routes that have different MULTI_EXIT_DISC attribute SHALL NOT
be aggregated.

Path attributes that have different type codes can not be aggregated
together. Path attributes of the same type code may be aggregated,
according to the following rules:

NEXT_HOP: When aggregating routes that have different NEXT_HOP
attribute, the NEXT_HOP attribute of the aggregated route SHALL
identify an interface on the router that performs the aggregation.

This met with agreement.

Dimitry asked if the "Routes that have different MULTI_EXIT_DESC attribute
SHALL NOT be aggregated." sentance was unnecessary since it should be a
matter of local policy.  Jeff replied that it has been mentioned that
removing this stipulation can cause routing loops.

We are at consensus with this issue.