Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt

"Ilya Varlashkin" <Ilya.Varlashkin@de.easynet.net> Wed, 30 April 2008 15:54 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D61643A6B1B; Wed, 30 Apr 2008 08:54:45 -0700 (PDT)
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2C443A6DE3 for <idr@core3.amsl.com>; Wed, 30 Apr 2008 08:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWbEVx4hGl5e for <idr@core3.amsl.com>; Wed, 30 Apr 2008 08:54:44 -0700 (PDT)
Received: from softy.ision.net (softy.ision.net [194.163.250.97]) by core3.amsl.com (Postfix) with ESMTP id A041D3A699C for <idr@ietf.org>; Wed, 30 Apr 2008 08:54:43 -0700 (PDT)
Received: from paul.de.easynet.net ([195.180.208.152] helo=paul.adoffice.de.easynet.net) by softy.ision.net with esmtp (Exim 4.50) id 1JrEdo-0001zC-Ni; Wed, 30 Apr 2008 17:54:44 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 30 Apr 2008 17:54:44 +0200
Message-ID: <7000E71D8C525042A815432358B2F1240138D465@paul.adoffice.local.de.easynet.net>
In-Reply-To: <DE879141-E245-4051-A04D-9FF5CF97F892@bgp.nu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt
Thread-Index: Aciq1xhWgztVONHoTbi+2B249jaQOgAAVTSQ
References: <20080425213001.4EB133A69E7@core3.amsl.com> <64E4CA6A-B8E4-4390-BDA6-39EF28E95AEA@tcb.net> <7000E71D8C525042A815432358B2F1240138D45E@paul.adoffice.local.de.easynet.net> <DE879141-E245-4051-A04D-9FF5CF97F892@bgp.nu>
From: Ilya Varlashkin <Ilya.Varlashkin@de.easynet.net>
To: "John G. Scudder" <jgs@bgp.nu>, Danny McPherson <danny@tcb.net>
Cc: idr <idr@ietf.org>
Subject: Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

John, 

> -----Original Message-----
> would ever try to force you to adopt this model.  The 
> question is why  
> you think others shouldn't be allowed to configure their 
> networks that  
> way.
> 

I do not worry that someone will force me, nor do I want to tell others
how to configure and operate their network. But adding this specific
functionality will require changes in one of the core BGP parts. 

> With regard to some of your other points, I think the 
> proposed feature  
> should be only be enabled if configured, i.e. the default should be  
> the current behavior.  The draft should be updated to say this  
> explicitly.  As long as it defaults to off, usage of the feature  
> becomes a "consenting adults" thing.  As for your observations  

Even if this feature is off by default, it's still addition of the new
code to the core part of BGP. So there is risk that things will go wrong
with implementing the code (I do not worry about enabling feature since
I don't have to enable it) and this may destabilise current BGP
functionality. Since hardly any vendor will ship two versions of
router's software - one with and one without new code, it's obvious that
one day even networks that don't need this functionality will have to
become field testers of the new BGP code, and this is exactly part I
worry about.

> In fact, very little new RR code would be required to take advantage  
> of the feature.  The RR needs to be able to match on an RT, 

Ok I see you point for this one.

Kind regards,
iLya
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr