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

Danny McPherson <> Wed, 30 April 2008 22:39 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id 018613A697F; Wed, 30 Apr 2008 15:39:23 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D36F13A6969 for <>; Wed, 30 Apr 2008 15:39:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.542
X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tW9RaOjy19bG for <>; Wed, 30 Apr 2008 15:39:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D531B3A6848 for <>; Wed, 30 Apr 2008 15:39:20 -0700 (PDT)
Received: by (Postfix, from userid 0) id AC59C2680D7; Wed, 30 Apr 2008 16:39:23 -0600 (MDT)
Received: from [] (VDSL-151-118-146-11.DNVR.QWEST.NET []) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by with SMTP; Wed, 30 Apr 2008 16:39:23 -0600 (MDT) (envelope-from
X-Avenger: version=0.7.8;; client-ip=; client-port=57094; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0
Message-Id: <>
From: Danny McPherson <>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Wed, 30 Apr 2008 16:39:08 -0600
References: <> <> <> <> <> <><><><><><><> <> <>
X-Mailer: Apple Mail (2.919.2)
Cc: idr idr <>
Subject: Re: [Idr] Fwd:I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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

> 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

> **
> 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

> 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

> 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.


Idr mailing list