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

"John G. Scudder" <jgs@bgp.nu> Wed, 30 April 2008 17:48 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 1B1D23A6DD9; Wed, 30 Apr 2008 10:48:17 -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 9C3AF3A6DD9 for <idr@core3.amsl.com>; Wed, 30 Apr 2008 10:48:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.043
X-Spam-Level:
X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
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 LBG9-jFwvIgz for <idr@core3.amsl.com>; Wed, 30 Apr 2008 10:48:13 -0700 (PDT)
Received: from bgp.nu (bgp.nu [64.27.28.76]) by core3.amsl.com (Postfix) with ESMTP id 430673A6DB0 for <idr@ietf.org>; Wed, 30 Apr 2008 10:46:07 -0700 (PDT)
Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id F243253E1AF; Wed, 30 Apr 2008 13:46:09 -0400 (EDT)
X-Virus-Scanned: amavisd-new at bgp.nu
Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id nobvvzrdvA9B; Wed, 30 Apr 2008 13:45:55 -0400 (EDT)
Received: from [172.16.13.201] (dsl093-003-111.det1.dsl.speakeasy.net [66.93.3.111]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id CAA2653E0FC; Wed, 30 Apr 2008 13:45:54 -0400 (EDT)
Message-Id: <014A2382-C5CE-4657-B4DA-FC84D7772359@bgp.nu>
From: "John G. Scudder" <jgs@bgp.nu>
To: Danny McPherson <danny@tcb.net>
In-Reply-To: <39074353-26E5-4239-A193-E4DD84AE75A0@tcb.net>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Wed, 30 Apr 2008 13:45:53 -0400
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>
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 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?

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