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

"John G. Scudder" <jgs@bgp.nu> Wed, 30 April 2008 22:03 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 244C73A698C; Wed, 30 Apr 2008 15:03:33 -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 7DE503A684D for <idr@core3.amsl.com>; Wed, 30 Apr 2008 15:03:31 -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 Ih7WvK8sdi26 for <idr@core3.amsl.com>; Wed, 30 Apr 2008 15:03:30 -0700 (PDT)
Received: from bgp.nu (bgp.nu [64.27.28.76]) by core3.amsl.com (Postfix) with ESMTP id BB2A328C435 for <idr@ietf.org>; Wed, 30 Apr 2008 15:03:10 -0700 (PDT)
Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id 6A84453E1AF; Wed, 30 Apr 2008 18:03:13 -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 V8rVgUto1e79; Wed, 30 Apr 2008 18:03:07 -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 616FD53E0FC; Wed, 30 Apr 2008 18:03:07 -0400 (EDT)
Message-Id: <B8D6A07F-5E2F-480C-8BC2-AC49F6A36A16@bgp.nu>
From: "John G. Scudder" <jgs@bgp.nu>
To: Danny McPherson <danny@tcb.net>
In-Reply-To: <80A0A0C2-F44E-46F9-967A-BC2690EFC29D@tcb.net>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Wed, 30 Apr 2008 18:03:05 -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> <014A2382-C5CE-4657-B4DA-FC84D7772359@bgp.nu> <4686A93B-EF16-48DC-9775-1BD241575360@tcb.net> <F4023837-6087-45A9-8D43-D248F89A27EC@bgp.nu> <80A0A0C2-F44E-46F9-967A-BC2690EFC29D@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 5:19 PM, Danny McPherson wrote:
>> Do you really think that a client which doesn't interoperate with  
>> 2796
>> RRs is viable in a network at all?  Especially one which also  
>> violates
>> the base spec by not checking the NEXT_HOP?
>
> I've seen it before in a real network.

And did you think that client was behaving appropriately then?  If so,  
why did you think it was OK for the client to violate the base spec?   
Also, you mentioned that your "real network" example was from ~10  
years ago, so while it's interesting... do you think such clients are  
still likely to exist *today*?

> Well, upon thinking about this a bit more, it also seems silly to
> me that a network would be architected in such a way as to allow
> problems with an 'upstream' RR to affect connectivity between
> two VRFs on the same PE.  I'd think to an operator trying to ensure
> availability would be worth the configuration overhead, even if
> some folks consider the extra 'state' a wash.

I guess different operators have different views about where in the  
optimization space they want to live.  For that matter, if the  
(redundant pair of) RRs goes south, the PE's connectivity to the rest  
of the world is broken anyway, local connectivity is just a special  
case.  I can understand why the survival of that special case when the  
rest of the world is broken may not be seen as a deal-breaker.

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