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

"John G. Scudder" <jgs@juniper.net> Wed, 07 May 2008 14: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 729BA3A6938; Wed, 7 May 2008 07:44:26 -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 69F2C3A6974 for <idr@core3.amsl.com>; Wed, 7 May 2008 07:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 YCA4xGMTv8E7 for <idr@core3.amsl.com>; Wed, 7 May 2008 07:44:18 -0700 (PDT)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 8463A3A6938 for <idr@ietf.org>; Wed, 7 May 2008 07:43:57 -0700 (PDT)
Received: from source ([66.129.224.36]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Wed, 07 May 2008 07:43:30 PDT
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 May 2008 07:38:44 -0700
Received: from [172.16.13.201] ([172.16.13.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m47Echx27844; Wed, 7 May 2008 07:38:43 -0700 (PDT) (envelope-from jgs@juniper.net)
Message-Id: <B1A246D0-56A0-481F-984E-353BB0975C18@juniper.net>
From: "John G. Scudder" <jgs@juniper.net>
To: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <20080507141250.GA17332@scc.mi.org>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Wed, 07 May 2008 10:38:42 -0400
References: <20080506180029.GA26405@scc.mi.org> <9A3A6AC97A8CF44DACD99DC00BEC235A02F132D4@xmb-rtp-203.amer.cisco.com> <20080506194653.GA8171@scc.mi.org> <42F67934-71FE-4D36-B793-91A9B7122096@juniper.net> <20080506212850.GA21845@scc.mi.org> <F5EFC2D4-6F27-4E32-A462-6706E23B59FC@juniper.net> <20080507141250.GA17332@scc.mi.org>
X-Mailer: Apple Mail (2.919.2)
X-OriginalArrivalTime: 07 May 2008 14:38:44.0814 (UTC) FILETIME=[0D5D26E0:01C8B050]
Cc: idr@ietf.org, "RAMSAROOP, JEEWAN P, ATTLABS" <jramsaroop@att.com>, "NGUYEN, HAN Q, ATTLABS" <hnguyen@att.com>, "LONGHITANO, ANTHONY C, ATTLABS" <aclonghitano@att.com>
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 May 7, 2008, at 10:12 AM, Jeffrey Haas wrote:
>> That
>> actually would be OK as long as the other rules I've cited above are
>> followed, i.e. the route may only go into a VRF other than the
>> source.  In that sense, the ACCEPT_OWN community is belt-and-
>> suspenders rather than being strictly necessary.
>
> Exactly.  With such a knob, no additional well known communities are
> really required.  However, for your use case, you still require
> information present to help prevent loops.

Actually given the other rules we've discussed I don't see where  
there's potential for loops even absent the ACCEPT_OWN community,  
which is why I referred to it as "belt-and-suspenders".  If you can  
think of a specific loop scenario, I'd be interested to hear it.

> This would potentially
> change your draft from "add this well known community" to "routers may
> be configured to accept their own routes under these circumstances".
> This potentially moves ACCEPT_OWN to an advisory community.


Seems like an editorial rather than normative change -- essentially  
emphasizing that the behavior is controlled by configuration and  
defaults off.  As such, I don't think I'd have a problem with it.

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