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

"John G. Scudder" <jgs@bgp.nu> Wed, 30 April 2008 20:44 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 A56FA3A6AB7; Wed, 30 Apr 2008 13:44:53 -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 0AB133A6943 for <idr@core3.amsl.com>; Wed, 30 Apr 2008 13:44:52 -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 jzpCqQQFZSl7 for <idr@core3.amsl.com>; Wed, 30 Apr 2008 13:44:51 -0700 (PDT)
Received: from bgp.nu (bgp.nu [64.27.28.76]) by core3.amsl.com (Postfix) with ESMTP id 1ED0A3A694A for <idr@ietf.org>; Wed, 30 Apr 2008 13:44:51 -0700 (PDT)
Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id C1C2B53E1AF; Wed, 30 Apr 2008 16:44:53 -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 RarcPpziRJfV; Wed, 30 Apr 2008 16:44:47 -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 7ABF153E0FC; Wed, 30 Apr 2008 16:44:46 -0400 (EDT)
Message-Id: <F4023837-6087-45A9-8D43-D248F89A27EC@bgp.nu>
From: "John G. Scudder" <jgs@bgp.nu>
To: Danny McPherson <danny@tcb.net>
In-Reply-To: <4686A93B-EF16-48DC-9775-1BD241575360@tcb.net>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Wed, 30 Apr 2008 16:44:45 -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>
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:12 PM, Danny McPherson wrote:
> On Apr 30, 2008, at 11:45 AM, John G. Scudder wrote:
>> 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.
>
> Even your draft disagrees with this, else it wouldn't mention
> the disabling RFC 1966 behavior

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.

> (as opposed to the discard
> based on ORIGINATOR_ID on the client that RFC 2796
> introduced -  for no valid _protocol reason, mind you, which
> annoys me considerably).  Along this vein, I would be quite
> interested in someone providing an explanation of why this
> behavior was changed from 1966 to 2796....

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

>> 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.)
>
> Right, but see my point above...  This assumes all clients employ
> the discard behavior of 2796.

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?

>> 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.
>
> I'm sure there is demand to make 2547 configuration simpler, but
> that doesn't mean it's something we should change fundamental
> BGP behavior to facilitate.  I would be interested in here from your
> co-authors..

I'm sure one of them will chime in.

>> What is the redundant network state you're referring to?  The  
>> "address
>> family overlays" I snipped out of the quote?
>
> No, I've come to accept the AF overlays..   What troubles me is the  
> fact
> that we're using BGP to enable a RR to modify an update learned from
> a client, and to reflect that update back to that client - just does  
> seem
> good routing protocol hygiene to me, to save configuration overhead
> on the client, when it'll surely be further required on the RRs.

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.

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