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

Jeffrey Haas <jhaas@pfrc.org> Tue, 06 May 2008 19:46 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 44A5A3A700A; Tue, 6 May 2008 12:46:57 -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 E246C3A701E for <idr@core3.amsl.com>; Tue, 6 May 2008 12:46:55 -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 MNSEycw8wxMP for <idr@core3.amsl.com>; Tue, 6 May 2008 12:46:55 -0700 (PDT)
Received: from manos.scc.mi.org (manos.scc.mi.org [204.11.140.250]) by core3.amsl.com (Postfix) with ESMTP id 1CCFF3A6839 for <idr@ietf.org>; Tue, 6 May 2008 12:46:55 -0700 (PDT)
Received: by manos.scc.mi.org (Postfix, from userid 1025) id 258E84E49C; Tue, 6 May 2008 15:46:53 -0400 (EDT)
Date: Tue, 06 May 2008 15:46:53 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Jim Guichard (jguichar)" <jguichar@cisco.com>
Message-ID: <20080506194653.GA8171@scc.mi.org>
References: <20080506180029.GA26405@scc.mi.org> <9A3A6AC97A8CF44DACD99DC00BEC235A02F132D4@xmb-rtp-203.amer.cisco.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9A3A6AC97A8CF44DACD99DC00BEC235A02F132D4@xmb-rtp-203.amer.cisco.com>
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

[Note to John S. - I was definitely the confused one here.  The issue is
not that the routers in question can't be configured to handle the
leaking from one VRF to another internally without a BGP announcement.
The issue is that the users don't want the administrative overhead of
doing that at the configuration level for each VRF on each router.]

On Tue, May 06, 2008 at 02:07:09PM -0400, Jim Guichard (jguichar) wrote:
> Lets say VPN-a uses RT 100:1 and VPN-b uses RT 100:2. In order to create
> an extranet you need to import RT 100:2 into VPN-a and RT 100:1 into
> VPN-b. This is an additional import statement. However, if you change
> the VPN-b route RT values at the RR then VPN-a can import based on RT
> 100:1.

Ok, the typical configuration on the router is what I expected it to be.
The piece I didn't understand was the alteration of the RT via "BGP VPN
route server".

> > 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.
> 
> It is 100% likely and indeed necessary should you want different VPNs.

To clarify: This wasn't per-VPN.  My comment was effectively each box
was it's own VPN.  That's not what you had meant.

My apologies for the long message train to reach this conclusion.

I still recommend to the authors that they don't consider a well-known
standard community.  Please consider either using a new extended
community or adding a configuration knob for the existing route-target
community.  I think that would serve your requirements without otherwise
complicating existing non-VPN situations.

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