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

Jeffrey Haas <jhaas@pfrc.org> Tue, 06 May 2008 18:00 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 407BC28C412; Tue, 6 May 2008 11:00:34 -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 D86933A6B89 for <idr@core3.amsl.com>; Tue, 6 May 2008 11:00:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 OvHy-8Zh7wkS for <idr@core3.amsl.com>; Tue, 6 May 2008 11:00:31 -0700 (PDT)
Received: from manos.scc.mi.org (manos.scc.mi.org [204.11.140.250]) by core3.amsl.com (Postfix) with ESMTP id C59363A6A08 for <idr@ietf.org>; Tue, 6 May 2008 11:00:31 -0700 (PDT)
Received: by manos.scc.mi.org (Postfix, from userid 1025) id 024274E4AF; Tue, 6 May 2008 14:00:30 -0400 (EDT)
Date: Tue, 6 May 2008 14:00:29 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "John G. Scudder" <jgs@juniper.net>, "Jim Guichard (jguichar)" <jguichar@cisco.com>
Message-ID: <20080506180029.GA26405@scc.mi.org>
References: <046A97A5-D1A9-4576-A961-0E4DE1DFEB0D@juniper.net> <9A3A6AC97A8CF44DACD99DC00BEC235A02F131A1@xmb-rtp-203.amer.cisco.com> <A1F50CB516D211409DFD05D6B3CE6D300ED2856E@KCCLUST06EVS1.ugd.att.com> <20080506111523.GA9122@scc.mi.org> <046A97A5-D1A9-4576-A961-0E4DE1DFEB0D@juniper.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9A3A6AC97A8CF44DACD99DC00BEC235A02F131A1@xmb-rtp-203.amer.cisco.com> <046A97A5-D1A9-4576-A961-0E4DE1DFEB0D@juniper.net>
User-Agent: Mutt/1.5.9i
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

John,

On Tue, May 06, 2008 at 10:40:25AM -0400, John G. Scudder wrote:
> Can you elaborate on this point?  One of us is missing something and  
> Murphy's Law says that quite possibly it's me.

It's probably not you.  I'll respond to your points in Jim's reply.

On Tue, May 06, 2008 at 10:47:46AM -0400, Jim Guichard (jguichar) wrote:
> I believe what is being proposed is to add the ability to
> change the RT value of an exported route at the RR so as it becomes the
> RT value of an importing VRF at the originating PE (the accept-own is a
> by-product of the fact that the extranet happens to be on the same PE).

Typical VRF configuration is import-route-target A and
export-route-target B.  If A == B for some A and B in the extended
community set they're in the same VPN.

I'm curious as to the configuration of the route targets that would
require this to be done.  I hadn't thought about the case where the RR
is actively manipulating the route-targets.  If the goal is to stitch
together a single set of VRFs, you have the additional problem of
needing to constrain where the route is reflected.  

If it's across multiple PEs, this implies something along the lines of
RT A and RT B are distinct on a per VRF basis.  This seems somewhat
unlikely (at least on the completely distinct basis) since it wouldn't
scale well for many VRFs being in the same VPN.

Could you clarify on the likely setup for this feature?

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