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

Danny McPherson <danny@tcb.net> Wed, 30 April 2008 22:28 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 3DB6A3A6AD7; Wed, 30 Apr 2008 15:28:00 -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 DD8F03A6AD7 for <idr@core3.amsl.com>; Wed, 30 Apr 2008 15:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.537
X-Spam-Level:
X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599]
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 Zzd53rE5hFU5 for <idr@core3.amsl.com>; Wed, 30 Apr 2008 15:27:58 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id F16133A6A0A for <idr@ietf.org>; Wed, 30 Apr 2008 15:27:57 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id A9EA22680D7; Wed, 30 Apr 2008 16:28:00 -0600 (MDT)
Received: from [192.168.1.103] (VDSL-151-118-146-11.DNVR.QWEST.NET [151.118.146.11]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 30 Apr 2008 16:28:00 -0600 (MDT) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=151.118.146.11; client-port=57085; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0
Message-Id: <59351B8C-437C-4803-833B-D8A5036667E0@tcb.net>
From: Danny McPherson <danny@tcb.net>
To: "John G. Scudder" <jgs@bgp.nu>
In-Reply-To: <B8D6A07F-5E2F-480C-8BC2-AC49F6A36A16@bgp.nu>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Wed, 30 Apr 2008 16:27:44 -0600
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> <B8D6A07F-5E2F-480C-8BC2-AC49F6A36A16@bgp.nu>
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 4:03 PM, John G. Scudder wrote:
> And did you think that client was behaving appropriately then?

No, neither did your current employer.  But the other vendor
pointed to the spec changes and said they were compliant and
the client needs to know it's a client and needs to drop the
extraneous updates.

I'd be keen on revamping 2796 again to remove that local
optimization, personally.  I'm no fan of expanding upon it.

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

Depends on whether I think the spec change was
appropriate or not.  Again, local optimizations that
result in much more system-wide state I'm not a big
fan of.

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

If they're redundant, then there's dual the amount of
extraneous state, and they may still share a common
switched link layer or the like.

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

Perhaps.  I wouldn't buy such a service from an operator
that designed their network in this manner, you might (although
I doubt it :-), but fair enough.

I believe folks that are implementing this may want to help
their customers understand this case, and I think the
draft would benefit from it's discussion as well.

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