[147100] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

draft-ietf-idr-as0-00 (bgp update destroying transit on redback

daemon@ATHENA.MIT.EDU (Daniel Ginsburg)
Fri Dec 2 08:13:51 2011

From: Daniel Ginsburg <dbg@net-geek.org>
In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se>
Date: Fri, 2 Dec 2011 17:12:48 +0400
To: Jeff Tantsura <jeff.tantsura@ericsson.com>,
 Warren Kumari <warren@kumari.net>
Cc: idr@ietf.org, nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

Hi,

This is true that "no-aggregator-id" knob zeroes out the AGGREGATOR =
attribute.

The knob, as far as I was able to find out, dates back to gated and =
there's a reason why it was introduced - it helps to avoid unnecessary =
updates. Assume that an aggregate route is generated by two (or more) =
speakers in the network. These two aggregates differ only in AGGREGATOR =
attribute. One of the aggregates is preferred within the network (due to =
IGP metric, for instance, or any other reasons) and is announced out. =
Now if something changes within the network and the other instance of =
the aggregate becomes preferred, the network has to issue an outward =
update different from the previous only in AGGREGATOR attribute, which =
is completely superfluous.

If the network employs the "no-aggregator-id" knob to zero out the =
AGGREGATOR attribute, both instances of the aggregate route are =
completely equivalent, and no redundant outward updates have to be send =
if one instance becomes better than another due to some internal event, =
which nobody in the Internet cares about.

In other words, the "no-aggregator-id" knob has valid operational =
reasons to be used. And, IMHO, the draft-ietf-idr-as0-00 should not =
prohibit AS0 in AGGREGATOR attribute.

On 02.12.2011, at 1:56, Jeff Tantsura wrote:

> Hi,
>=20
> Let me take it over from now on, I'm the IP Routing/MPLS Product =
Manager at Ericsson responsible for all routing protocols.
> There's nothing wrong in checking ASN in AGGREGATOR, we don't really =
want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 =
(draft-ietf-idr-as0-00) came into the worlds.
>=20
> To my knowledge - the only vendor which allows changing ASN in =
AGGREGATOR is Juniper, see "no-aggregator-id", in the past I've tried to =
talk to Yakov about it, without any results though.=20
> So for those who have it configured - please rethink whether you =
really need it.
>=20
> As for SEOS - understanding that this badly affects our customers and =
not having draft-ietf-idr-error-handling fully implemented yet, we will =
temporarily disable this check in our code.
> Patch will be made available.
>=20
> Please contact me for any further clarifications.
>=20
> Regards,
> Jeff
>=20
> P.S. Warren has recently  included AGGREGATOR in the draft, please see
>=20
> 2. Behavior
>   This document specifies that a BGP speaker MUST NOT originate or
>   propagate a route with an AS number of zero.  If a BGP speaker
>   receives a route which has an AS number of zero in the AS_PATH (or
>   AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW.
>   This same behavior applies to routes containing zero as the
>   Aggregator or AS4 Aggregator.
>=20



home help back first fref pref prev next nref lref last post