[147167] in North American Network Operators' Group
Re: [Idr] draft-ietf-idr-as0-00 (bgp update destroying transit on
daemon@ATHENA.MIT.EDU (Brian Dickson)
Sat Dec 3 12:23:59 2011
In-Reply-To: <26E0D18F-F80E-4EF0-B49A-6FF59957B0C3@net-geek.org>
Date: Sat, 3 Dec 2011 12:22:56 -0500
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Daniel Ginsburg <dbg@net-geek.org>
Cc: idr@ietf.org, nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Can anyone familiar with this knob and its usage, answer a question:
Would anything break, in terms of use of that knob, if instead of
"zeroing" the AGGREGATOR, the local AS (as seen from the outside
world, in the case of confederations) were used?
Would the functionality of the knob, in reducing updates, be preserved?
Would routes be considered malformed or would it trigger any other bad beha=
vior?
Perhaps this is a way of resolving the conflict between this knob and
the AS0 draft?
Brian
On Fri, Dec 2, 2011 at 8:12 AM, Daniel Ginsburg <dbg@net-geek.org> wrote:
> Hi,
>
> This is true that "no-aggregator-id" knob zeroes out the AGGREGATOR attri=
bute.
>
> 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 th=
e network. These two aggregates differ only in AGGREGATOR attribute. One of=
the aggregates is preferred within the network (due to IGP metric, for ins=
tance, or any other reasons) and is announced out. Now if something changes=
within the network and the other instance of the aggregate becomes preferr=
ed, 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 AGGREG=
ATOR attribute, both instances of the aggregate route are completely equiva=
lent, and no redundant outward updates have to be send if one instance beco=
mes better than another due to some internal event, which nobody in the Int=
ernet 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 i=
n AGGREGATOR attribute.
>
> On 02.12.2011, at 1:56, Jeff Tantsura wrote:
>
>> Hi,
>>
>> 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 wan=
t see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-=
00) came into the worlds.
>>
>> To my knowledge - the only vendor which allows changing ASN in AGGREGATO=
R is Juniper, see "no-aggregator-id", in the past I've tried to talk to Yak=
ov about it, without any results though.
>> So for those who have it configured - please rethink whether you really =
need it.
>>
>> As for SEOS - understanding that this badly affects our customers and no=
t having draft-ietf-idr-error-handling fully implemented yet, we will tempo=
rarily disable this check in our code.
>> Patch will be made available.
>>
>> Please contact me for any further clarifications.
>>
>> Regards,
>> Jeff
>>
>> P.S. Warren has recently =A0included AGGREGATOR in the draft, please see
>>
>> 2. Behavior
>> =A0 This document specifies that a BGP speaker MUST NOT originate or
>> =A0 propagate a route with an AS number of zero. =A0If a BGP speaker
>> =A0 receives a route which has an AS number of zero in the AS_PATH (or
>> =A0 AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW.
>> =A0 This same behavior applies to routes containing zero as the
>> =A0 Aggregator or AS4 Aggregator.
>>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
