Re: [Idr] draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?)

Jeff Tantsura <jeff.tantsura@ericsson.com> Sat, 03 December 2011 08:21 UTC

Return-Path: <jeff.tantsura@ericsson.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD3921F8E38 for <idr@ietfa.amsl.com>; Sat, 3 Dec 2011 00:21:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTb+RHK5sKMC for <idr@ietfa.amsl.com>; Sat, 3 Dec 2011 00:21:39 -0800 (PST)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id D365E21F8E31 for <idr@ietf.org>; Sat, 3 Dec 2011 00:21:39 -0800 (PST)
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pB38LZwS021722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Dec 2011 02:21:36 -0600
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sat, 3 Dec 2011 03:21:35 -0500
From: Jeff Tantsura <jeff.tantsura@ericsson.com>
To: Daniel Ginsburg <dbg@net-geek.org>, Warren Kumari <warren@kumari.net>
Date: Sat, 03 Dec 2011 03:21:33 -0500
Thread-Topic: draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?)
Thread-Index: Acyw9CSfi+VCcj6wQpS4Cam5+Cfc3QAnGVPw
Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6181C2EDF8A@EUSAACMS0701.eamcs.ericsson.se>
References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C25624E@EUSAACMS0701.eamcs.ericsson.se> <26E0D18F-F80E-4EF0-B49A-6FF59957B0C3@net-geek.org>
In-Reply-To: <26E0D18F-F80E-4EF0-B49A-6FF59957B0C3@net-geek.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org" <idr@ietf.org>, "nanog@nanog.org" <nanog@nanog.org>
Subject: Re: [Idr] draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Dec 2011 08:21:40 -0000

Hi Daniel,

I do understand the use of it however have my doubts about usability as such, 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 illigal, are you (your customers) OK with it? 
Thanks!

-----Original Message-----
From: Daniel Ginsburg [mailto:dbg@net-geek.org] 
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 routers ?)

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,
> 
> 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.
> 
> 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. 
> 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 not having draft-ietf-idr-error-handling fully implemented yet, we will temporarily 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  included AGGREGATOR in the draft, please see
> 
> 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.
>