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

"UTTARO, JAMES, ATTLABS" <uttaro@att.com> Tue, 06 May 2008 18:32 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 A204228C457; Tue, 6 May 2008 11:32:02 -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 4EB1928C478 for <idr@core3.amsl.com>; Tue, 6 May 2008 11:32:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.141
X-Spam-Level:
X-Spam-Status: No, score=-105.141 tagged_above=-999 required=5 tests=[AWL=1.458, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 8Ra70hJenlCt for <idr@core3.amsl.com>; Tue, 6 May 2008 11:32:00 -0700 (PDT)
Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by core3.amsl.com (Postfix) with ESMTP id C8F5D28C454 for <idr@ietf.org>; Tue, 6 May 2008 11:31:14 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: uttaro@att.com
X-Msg-Ref: server-4.tower-203.messagelabs.com!1210098662!18314467!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.160.20.54]
Received: (qmail 5381 invoked from network); 6 May 2008 18:31:03 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-4.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 6 May 2008 18:31:03 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m46IVBPn009099; Tue, 6 May 2008 14:31:11 -0400
Received: from kcclust06evs1.ugd.att.com (kcst11.ugd.att.com [135.38.164.88]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m46IV61e009041; Tue, 6 May 2008 14:31:07 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 6 May 2008 13:31:06 -0500
Message-ID: <A1F50CB516D211409DFD05D6B3CE6D300ED28578@KCCLUST06EVS1.ugd.att.com>
In-Reply-To: <20080506180029.GA26405@scc.mi.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt
Thread-Index: AcivoxlfjOjcgwJRRfeFpOUuFLpyrQAAt33A
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> <20080506180029.GA26405@scc.mi.org>
From: "UTTARO, JAMES, ATTLABS" <uttaro@att.com>
To: "Jeffrey Haas" <jhaas@pfrc.org>, "John G. Scudder" <jgs@juniper.net>, "Jim Guichard (jguichar)" <jguichar@cisco.com>
Cc: idr@ietf.org, "LONGHITANO, ANTHONY C, ATTLABS" <aclonghitano@att.com>, "RAMSAROOP, JEEWAN P, ATTLABS" <jramsaroop@att.com>, "NGUYEN, HAN Q, ATTLABS" <hnguyen@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


Comments In-Line.. 

-----Original Message-----
From: Jeffrey Haas [mailto:jhaas@pfrc.org] 
Sent: Tuesday, May 06, 2008 2:00 PM
To: John G. Scudder; Jim Guichard (jguichar)
Cc: Jeffrey Haas; UTTARO, JAMES, ATTLABS; idr@ietf.org; LONGHITANO,
ANTHONY C, ATTLABS; RAMSAROOP, JEEWAN P, ATTLABS; NGUYEN, HAN Q, ATTLABS
Subject: Re: [Idr] Fwd: I-D
ACTION:draft-pmohapat-idr-acceptown-community-01.txt

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.

J.Uttaro> In most cases VRFs have the same Import/Export RT value. Hub
and Spoke and Arbitrary topologies would not.

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.

J.Uttaro>
Yes.. The centralized point could decide to reflect to only a sub-set of
PEs that a VPN participates in. A more intelligent RR could be made to
have this capability. But IMO I believe that the stitch would be on a
per prefix basis from VPN A -> VPN B and vice versa across the entire
set of PEs that these VPNs participate in.

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.

J.Uttaro> 
I don't know if I fully understand your question here. The setup would
be VPN A and VPN B would be instantiated on a set of PEs. All VRFs
associated with VPN A use RT1, All VRF associated with VPN B use RT2. We
want to stitch some X/24 from VPN A into VPN B and Y/24 from VPN B to
VPN A. X/24 is advertised from PE to RR, X/24 has RT1, RR attaches RT2
to X/24 and reflects to all speakers. The ACCEPT-OWN takes care of the
case where X/24 is advertised from a PE that also instantiates VPN B.

Could you clarify on the likely setup for this feature?

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