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

"John G. Scudder" <> Wed, 30 April 2008 15:30 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id 6EF1A28C3A2; Wed, 30 Apr 2008 08:30:17 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2A4E28C3D9 for <>; Wed, 30 Apr 2008 08:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.043
X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AQjLk0siQMx7 for <>; Wed, 30 Apr 2008 08:30:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CEFE928C3D3 for <>; Wed, 30 Apr 2008 08:30:08 -0700 (PDT)
Received: from localhost ( []) by (Postfix) with ESMTP id B762153E1F4; Wed, 30 Apr 2008 11:30:11 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id fXZFZJI0zhyZ; Wed, 30 Apr 2008 11:30:03 -0400 (EDT)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTP id C5C5353E0FC; Wed, 30 Apr 2008 11:30:02 -0400 (EDT)
Message-Id: <>
From: "John G. Scudder" <>
To: Ilya Varlashkin <>, Danny McPherson <>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Wed, 30 Apr 2008 11:30:01 -0400
References: <> <> <>
X-Mailer: Apple Mail (2.919.2)
Cc: 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


I get that you have a bad feeling about the idea.  Can you provide  
some specifics, though?  As far as I can tell, the proposed extension  
is safe (for the same value of "safe" as the rest of the  
protocol...).  See also my comments below regarding defaulting it off.


The main point of your comments seems to be "I would never configure  
my network that way".  You also make some assumptions about the  
organizational structure of the network operator.  Of course, nobody  
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  

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  
regarding specific deployments (e.g., disabled client-to-client  
reflection) I think it's reasonable to ask that the network operator  
know what they're doing before enabling the feature and will avoid  
using configurations which are broken!  This is no different than the  
situation today, since the possibility to configure the protocol in  
broken ways has always existed, nor is it unique to BGP.

Finally, I don't agree with this point:

> Usually RR's do not have specific VPN's defined and just relay routes
> based on generic BGP rules. ACCEPT_OWN will require RR to be aware at
> least of some VPN's (many in fact, else it doesn't make sense). This
> will require extra work on RR part, extra data structures, code,  
> meaning
> more opportunities for things to go wrong.

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, add an RT,  
and add the well-known community.  Matching and adding RTs (which are  
just extended communities) and adding other communities is existing  
functionality.  This requires additional configuration, but little or  
no new code.


Idr mailing list