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

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

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id 1B1D23A6DD9; Wed, 30 Apr 2008 10:48:17 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C3AF3A6DD9 for <>; Wed, 30 Apr 2008 10:48: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=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LBG9-jFwvIgz for <>; Wed, 30 Apr 2008 10:48:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 430673A6DB0 for <>; Wed, 30 Apr 2008 10:46:07 -0700 (PDT)
Received: from localhost ( []) by (Postfix) with ESMTP id F243253E1AF; Wed, 30 Apr 2008 13:46:09 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id nobvvzrdvA9B; Wed, 30 Apr 2008 13:45:55 -0400 (EDT)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTP id CAA2653E0FC; Wed, 30 Apr 2008 13:45:54 -0400 (EDT)
Message-Id: <>
From: "John G. Scudder" <>
To: Danny McPherson <>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Wed, 30 Apr 2008 13:45:53 -0400
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 12:06 PM, Danny McPherson wrote:
> Take, for example, the case where the client doesn't know how
> to handle the new community and some routing information loop
> results.

The nice thing is that the feature is backward compatible and fails  
safe -- if the client doesn't know how to handle the community, then  
it sees itself in the ORIGINATOR_ID and drops the route.  No route, no  
routing information loop.  Granted the behavior of dropping the route  
is undesired, but not horrible.

> I saw this occur in a real network when vendor 'n' changed their
> RR behavior to that of 2796 and reflected routes back to clients
> while the clients, vendor 'm', didn't know they were supposed to
> drop the routes.

Interesting -- one would have expected the vendor 'm' router to drop  
the routes even if it didn't understand ORIGINATOR_ID, due to the  
NEXT_HOP check.  I guess if the NEXT_HOP were getting rewritten...

But in any event this particular case is academic because of the "fail  
safe" behavior discussed above -- any client that interoperates with a  
2796 RR will fail safe.  (Any client that doesn't interoperate with a  
2796 RR is arguably pretty broken at this point.)

> How much configuration overhead is actually being saved
> on the PEs that justifies changing basic BGP specification
> behavior

One of my co-authors may want to address this point.  From my PoV,  
suffice it to say there's real demand for the feature.

> and introducing even more redundant network
> state?

What is the redundant network state you're referring to?  The "address  
family overlays" I snipped out of the quote?  Something else?

Idr mailing list