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

Danny McPherson <danny@tcb.net> Wed, 30 April 2008 22:39 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 018613A697F; Wed, 30 Apr 2008 15:39:23 -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 D36F13A6969 for <idr@core3.amsl.com>; Wed, 30 Apr 2008 15:39:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.542
X-Spam-Level:
X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 tW9RaOjy19bG for <idr@core3.amsl.com>; Wed, 30 Apr 2008 15:39:20 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id D531B3A6848 for <idr@ietf.org>; Wed, 30 Apr 2008 15:39:20 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id AC59C2680D7; Wed, 30 Apr 2008 16:39:23 -0600 (MDT)
Received: from [192.168.1.103] (VDSL-151-118-146-11.DNVR.QWEST.NET [151.118.146.11]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 30 Apr 2008 16:39:23 -0600 (MDT) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=151.118.146.11; client-port=57094; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0
Message-Id: <157A9EDC-B512-4C05-A257-72D70DFB44FA@tcb.net>
From: Danny McPherson <danny@tcb.net>
To: raszuk@juniper.net
In-Reply-To: <4818ECF1.1030909@juniper.net>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Wed, 30 Apr 2008 16:39:08 -0600
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> <39074353-26E5-4239-A193-E4DD84AE75A0@tcb.net> <014A2382-C5CE-4657-B4DA-FC84D7772359@bgp.nu><4686A93B-EF16-48DC-9775-1BD241575360@tcb.net><4818D897.3070804@cisco.com><DC5EBA07-BBE5-4D6D-9F3E-C40C66ACE34B@tcb.net><4818DB47.8040002@cisco.com><82B7CFF7-86CB-4DC7-BE53-29004128B5CB@tcb.net><4818DCFC.70001@cisco.com> <8D3C8A4B-B80B-4983-8DC7-A142FFA4B41C@tcb.net> <4818ECF1.1030909@juniper.net>
X-Mailer: Apple Mail (2.919.2)
Cc: idr 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

On Apr 30, 2008, at 4:04 PM, Robert Raszuk wrote:

> Hi Danny,
>
> In your below mail you are missing one fundamental practical data.

No, I'm not missing this, I understand it, I know why the spec
change was made.

> It is very cheap and easy to drop the unneeded route on inbound  
> while it
> is very CPU intensive to build separate updates to each peer.

Really?  Where's the line drawn?  What about when there are
one million updates being dropped?  I could probably make a
case for this today?  What about legit updates queued behind
these?  I don't believe introducing extraneous routing system
level state to allow more efficient update generation is a valid
excuse.

> With current link bandwith the amount of traffic generated due to that
> is just white noise.

Traffic wasn't the issue.  It's more CPU, memory, etc..  Just
because it's available doesn't mean it's free.

> IMHO based on the most common implementations at that time that was  
> the
> main reason for the RR spec change.

"Implementations" should be "implementation" there, not the
plural.

>
> **
>
> Now back to accept-own community I really see nothing wrong with it.  
> If
> you are trying to say this is bad just because some implementations to
> not support 2796 that's I am afraid wrong avenue.

Perhaps, if you're in the business of selling CPUs and memory.

> There are practical applications for this enhancement of which one is
> described in the draft.

Yes, one that introduces even local PE VRF-VRF connectivity
reliance on upstream RRs..

> As general rule of thumb I think there is need to support more
> automation in the network provisioning among many providers. There is
> also a demand in the market for more dynamic behavior of running
> applications. This is just right on this spot attempt to support one  
> of
> them.

Perhaps, but I think it ugly because of both clean routing hygiene
issues, and the network architectural fault considerations I've already
outlined.

>
> Cheers,
> R.
>
> PS. As to the comment from Ilya that this draft may break BGP
> implementations ... one needs to realize that conditional one more  
> check
> during inbound processing requires negligible amount of new BGP code.

Negligible, can you quantify that?  How many routes?  How much
churn?

> And I would like to point out that in most BGP implementations I am
> familiar with every month amount of code changes which go in even in  
> the
> fundamental parts of BGP assuming one may freeze all IDR work is much
> much much higher then such draft would require.

I don't understand what point you're making here.

-danny

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr