[147164] in North American Network Operators' Group
RE: draft-ietf-idr-as0-00 (bgp update destroying transit on
daemon@ATHENA.MIT.EDU (Jeff Tantsura)
Sat Dec 3 03:23:03 2011
From: Jeff Tantsura <jeff.tantsura@ericsson.com>
To: Daniel Ginsburg <dbg@net-geek.org>, Warren Kumari <warren@kumari.net>
Date: Sat, 3 Dec 2011 03:21:33 -0500
In-Reply-To: <26E0D18F-F80E-4EF0-B49A-6FF59957B0C3@net-geek.org>
Cc: "idr@ietf.org" <idr@ietf.org>, "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Hi Daniel,
I do understand the use of it however have my doubts about usability as suc=
h, I'd really like to see anyone using it for the reason below.
All of updates with ASN 0 I have seen in the past few years were there due =
to software bugs, not explicit configuration - same as this one.
Warren/ idr - I do support addition of AGGREGATOR in the draft
Regards,
Jeff
P.S. Jeffrey/John - this draft makes use of "no-aggregator-id" de facto i=
lligal, are you (your customers) OK with it?=20
Thanks!
-----Original Message-----
From: Daniel Ginsburg [mailto:dbg@net-geek.org]=20
Sent: Friday, December 02, 2011 5:13 AM
To: Jeff Tantsura; Warren Kumari
Cc: nanog@nanog.org; idr@ietf.org
Subject: draft-ietf-idr-as0-00 (bgp update destroying transit on redback ro=
uters ?)
Hi,
This is true that "no-aggregator-id" knob zeroes out the AGGREGATOR attribu=
te.
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. As=
sume that an aggregate route is generated by two (or more) speakers in the =
network. These two aggregates differ only in AGGREGATOR attribute. One of t=
he aggregates is preferred within the network (due to IGP metric, for insta=
nce, or any other reasons) and is announced out. Now if something changes w=
ithin the network and the other instance of the aggregate becomes preferred=
, the network has to issue an outward update different from the previous on=
ly in AGGREGATOR attribute, which is completely superfluous.
If the network employs the "no-aggregator-id" knob to zero out the AGGREGAT=
OR attribute, both instances of the aggregate route are completely equivale=
nt, and no redundant outward updates have to be send if one instance become=
s better than another due to some internal event, which nobody in the Inter=
net cares about.
In other words, the "no-aggregator-id" knob has valid operational reasons t=
o 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-0=
0) 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 Yako=
v about it, without any results though.=20
> So for those who have it configured - please rethink whether you really n=
eed 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 tempor=
arily 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
