Re: [Idr] Fwd:I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt
Robert Raszuk <raszuk@juniper.net> Wed, 30 April 2008 22:05 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 0FD803A6955; Wed, 30 Apr 2008 15:05:26 -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 54F4F3A6C63 for <idr@core3.amsl.com>; Wed, 30 Apr 2008 15:05:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 qbJTUCsJQnCN for <idr@core3.amsl.com>; Wed, 30 Apr 2008 15:05:23 -0700 (PDT)
Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 5ABFF3A6B17 for <idr@ietf.org>; Wed, 30 Apr 2008 15:05:02 -0700 (PDT)
Received: from source ([66.129.224.36]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Wed, 30 Apr 2008 15:04:46 PDT
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Apr 2008 15:04:37 -0700
Received: from [172.26.250.99] ([172.26.250.99]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m3UM4Zx93288; Wed, 30 Apr 2008 15:04:35 -0700 (PDT) (envelope-from raszuk@juniper.net)
Message-ID: <4818ECF1.1030909@juniper.net>
Date: Wed, 30 Apr 2008 15:04:33 -0700
From: Robert Raszuk <raszuk@juniper.net>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Danny McPherson <danny@tcb.net>
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>
In-Reply-To: <8D3C8A4B-B80B-4983-8DC7-A142FFA4B41C@tcb.net>
X-OriginalArrivalTime: 30 Apr 2008 22:04:37.0002 (UTC) FILETIME=[2E04D6A0:01C8AB0E]
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
Reply-To: raszuk@juniper.net
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
Hi Danny, In your below mail you are missing one fundamental practical data. 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. With current link bandwith the amount of traffic generated due to that is just white noise. IMHO based on the most common implementations at that time that was the main reason for the RR spec change. ** 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. There are practical applications for this enhancement of which one is described in the draft. 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. 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. 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. > On Apr 30, 2008, at 2:56 PM, Enke Chen wrote: > >> > >> Sure.. I don't like the idea of changing specs to accommodate > >> implementation optimizations. > > > > welcome to the real world :-) > > I do understand the reasoning behind this, although I > don't agree with it. > > In the real world, operators are complaining about DFZ > sizes (unique routes), and routing scalability, and churn, > little implementation tweaks that surface as base spec > changes like this have serious implications. > > Consider this 'optimization', for example. Now, most > clusters have at least 2-3 RRs, and many clients. If you've > got a single client that has 50k external paths that it sees > as best, and that client advertises them to the RRs, and > the RRs reflect them back, just so that the client can discard > them, then unless I'm confused, that little optimization just cost > you 150k (50k routes * 3 RRs, reflected back to client they > were learned from) worth update processing resources on > the clients. Not to mention implications on churn, or additional > layers of RR hierarchy, or the dynamics this introduces in a > REAL network. > > From a network-level perspective I don't see much of an > optimization at all, quite the contrary, actually. > > -danny > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr
- [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acceptow… Danny McPherson
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… Ilya Varlashkin
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… John G. Scudder
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… Ilya Varlashkin
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… Danny McPherson
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… John G. Scudder
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… Danny McPherson
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… Enke Chen
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… Danny McPherson
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… John G. Scudder
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… Enke Chen
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… Danny McPherson
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… Enke Chen
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… Danny McPherson
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… Danny McPherson
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… John G. Scudder
- Re: [Idr] Fwd:I-D ACTION:draft-pmohapat-idr-accep… Robert Raszuk
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… Danny McPherson
- Re: [Idr] Fwd:I-D ACTION:draft-pmohapat-idr-accep… Danny McPherson
- Re: [Idr] Fwd:I-D ACTION:draft-pmohapat-idr-accep… John G. Scudder
- Re: [Idr] Fwd:I-D ACTION:draft-pmohapat-idr-accep… Brian Dickson
- Re: [Idr] Fwd:I-D ACTION:draft-pmohapat-idr-accep… Robert Raszuk
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… UTTARO, JAMES, ATTLABS
- Re: [Idr] Fwd:I-D ACTION:draft-pmohapat-idr-accep… Danny McPherson
- [Idr] Route reflectors [was: Re: Fwd:I-D ACTION:d… John G. Scudder
- Re: [Idr] Route reflectors [was: Re: Fwd:I-D ACTI… Brian Dickson
- Re: [Idr] Fwd: I-DACTION:draft-pmohapat-idr-accep… Ilya Varlashkin
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… Jeffrey Haas
- Re: [Idr] Fwd: I-DACTION:draft-pmohapat-idr-accep… UTTARO, JAMES, ATTLABS
- Re: [Idr] Fwd: I-DACTION:draft-pmohapat-idr-accep… Danny McPherson
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… John G. Scudder
- Re: [Idr] Fwd: I-DACTION:draft-pmohapat-idr-accep… Jim Guichard (jguichar)
- Re: [Idr] Fwd: I-DACTION:draft-pmohapat-idr-accep… Ilya Varlashkin
- Re: [Idr] Fwd: I-DACTION:draft-pmohapat-idr-accep… John G. Scudder
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… Jeffrey Haas
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… Jim Guichard (jguichar)
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… UTTARO, JAMES, ATTLABS
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… Jeffrey Haas
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… John G. Scudder
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… Jeffrey Haas
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… John G. Scudder
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… Jeffrey Haas
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… John G. Scudder
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… Jeffrey Haas
- Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acce… David Ward
- Re: [Idr] Fwd: I-DACTION:draft-pmohapat-idr-accep… Pradosh Mohapatra (pmohapat)
- [Idr] draft-pmohapat-softwire-lb-00.txt Pradosh Mohapatra (pmohapat)