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

Danny McPherson <danny@tcb.net> Wed, 30 April 2008 21:19 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 970723A6CF4; Wed, 30 Apr 2008 14:19:50 -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 E902A3A6A4E for <idr@core3.amsl.com>; Wed, 30 Apr 2008 14:19:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Level:
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 7e34C6lQ4kgu for <idr@core3.amsl.com>; Wed, 30 Apr 2008 14:19:45 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 177323A6CD6 for <idr@ietf.org>; Wed, 30 Apr 2008 14:19:44 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id B3267268494; Wed, 30 Apr 2008 15:19:47 -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 15:19:47 -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=56772; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0
Message-Id: <80A0A0C2-F44E-46F9-967A-BC2690EFC29D@tcb.net>
From: Danny McPherson <danny@tcb.net>
To: "John G. Scudder" <jgs@bgp.nu>
In-Reply-To: <F4023837-6087-45A9-8D43-D248F89A27EC@bgp.nu>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Wed, 30 Apr 2008 15:19:31 -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>
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

>
> Not so.  The reason for that is to allow RR hierarchy to be used.
> Since the point of the draft is that the route's originator has to see
> it, it's important that RR's transparently pass it through.  I'm at a
> loss to see how you can interpret this as a tacit disagreement with my
> statement above.

Then why the 1966 text at all, that was my point.

> I suggest you take it up with that RFC's authors or check the archives
> -- I don't know the answer.  (I would say that implementability can  
> be  
> a "valid_protocol reason" though.)

Heh, that's the high road :-)

> Well, that OR they properly implement the base spec and drop routes
> which have themselves as NEXT_HOP.
>
> 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.

> OK, I don't see where this is "redundant network state" to speak of.
> Well, I guess for each route treated in this way there's one extra
> route exported from the RR to the route's originator -- but then again
> that is a route which the RR has to export to the rest of the network
> anyway.  So the RR does in effect no extra work.  The PE receiving the
> route does store a little extra stuff, but then again there would be
> some state for that route if it was locally exported between VRFs
> too.  Seems to me as though state -- both dynamic and configuration --
> is more-or-less a wash.

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.

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