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

"Jim Guichard (jguichar)" <jguichar@cisco.com> Tue, 06 May 2008 14:48 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 E46763A7065; Tue, 6 May 2008 07:48:42 -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 2E8C93A705E for <idr@core3.amsl.com>; Tue, 6 May 2008 07:48:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level:
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, 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 hXZKkCHwFpRj for <idr@core3.amsl.com>; Tue, 6 May 2008 07:48:40 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 2F2393A707F for <idr@ietf.org>; Tue, 6 May 2008 07:47:51 -0700 (PDT)
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 06 May 2008 07:47:48 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m46Elnp7027782; Tue, 6 May 2008 07:47:49 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m46EllGU015927; Tue, 6 May 2008 14:47:49 GMT
Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 May 2008 10:47:46 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 6 May 2008 10:47:46 -0400
Message-ID: <9A3A6AC97A8CF44DACD99DC00BEC235A02F131A1@xmb-rtp-203.amer.cisco.com>
In-Reply-To: <046A97A5-D1A9-4576-A961-0E4DE1DFEB0D@juniper.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Idr] Fwd: I-DACTION:draft-pmohapat-idr-acceptown-community-01.txt
Thread-Index: Acivhyr3f52elPyzTJ+vO2pilzhVqAAADCCQ
From: "Jim Guichard (jguichar)" <jguichar@cisco.com>
To: "John G. Scudder" <jgs@juniper.net>, "Jeffrey Haas" <jhaas@pfrc.org>
X-OriginalArrivalTime: 06 May 2008 14:47:46.0965 (UTC) FILETIME=[26191450:01C8AF88]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3281; t=1210085269; x=1210949269; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jguichar@cisco.com; z=From:=20=22Jim=20Guichard=20(jguichar)=22=20<jguichar@cisc o.com> |Subject:=20RE=3A=20[Idr]=20Fwd=3A=20I-DACTION=3Adraft-pmoh apat-idr-acceptown-community-01.txt |Sender:=20; bh=VjQqEJ7w+zRbKKUT6h/ACYB2j76H3tfokYnPm/qC2L8=; b=ccFFgwkelgqu737IxE927hHwgOrLktpgcPm2J8qzZfSTYFuC7G1tYqjZ5q EadBwweouJ8ttf2nfCr9g8UXjpVTMq4M4q+QKAJowT9yjm6opEXKEPjCRAHK tnTW8CW/C35mikouztcCtG9Hlr9YsdVEyFVSq8s43befm3NSEIwVg=;
Authentication-Results: sj-dkim-1; header.From=jguichar@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
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-DACTION: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

I think the key point to grasp is this; using existing technology if you
want to create an extranet then you have to manipulate the import/export
maps at the PE so as to import/export the locally assigned RTs for each
given VRF. It is also important to understand that this is on a
*per-VRF* basis e.g. there is no prefix-specific granularity (unless you
resort to import filters which is even worse). This is a *pain* with a
large number of PEs/VPNs, and is also not very flexible in a real
deployment. 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).
In this case the import/export configuration at the PEs remains
*unchanged*.

Jim Guichard 
Principal Engineer - MPLS Technologies
CCIE # 2069

> -----Original Message-----
> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of
John
> G. Scudder
> Sent: Tuesday, May 06, 2008 10:40 AM
> To: Jeffrey Haas
> Cc: idr@ietf.org; LONGHITANO, ANTHONY C, ATTLABS; RAMSAROOP, JEEWAN P,
> ATTLABS; NGUYEN,HAN Q, ATTLABS
> Subject: Re: [Idr] Fwd:
I-DACTION:draft-pmohapat-idr-acceptown-community-
> 01.txt
> 
> Jeff,
> 
> On May 6, 2008, at 7:15 AM, Jeffrey Haas wrote:
> >> In order to create a VPN
> >> stitch, the SP simply applies RTs to facilitate the stitch and
> >> reflects
> >> to all PEs. In order to deliver these services from a central
> >> location (
> >> RR, etc... ) we need to be able to reflect a route back to the PE
> >> that
> >> originated it. This is due to the fact the the two VPNs being
> >> stitched
> >> may reside on the same PE.
> >
> > I think one of the things I find unfortunate here is that this
feature
> > shouldn't be necessary.   The code path for sending your BGP
> > routes could simply reflect them internally back to your router as
an
> > "incoming route" when a route-target of interest is being appended
> > on an
> > outbound basis.
> >
> > Having been involved in an implementation that did this, it's
> > certainly
> > possible even if the code path is awkward.
> 
> Can you elaborate on this point?  One of us is missing something and
> Murphy's Law says that quite possibly it's me.  Jim's point, which
> you've quoted above, is that he desires for the RR to be the only
> control plane entity in the network which knows by configuration what
> the "route-target of interest" is.  As such, the control plane path
> from the PE to itself, as it were, is necessarily PE->RR->PE, since
> the PE doesn't know that it's interested in its own routes.  To make
> the terminology slightly less tormented, the desired control path is
> VRF1_on_PE->RR->VRF2_on_PE.  The VRF1->VRF2 on PE path isn't feasible
> in this use case because PE doesn't know that this relationship exists
> between the two VRFs, only the RR knows that.  (Of course that path is
> feasible if the use case admits of configuration on the PE.)
> 
> Thanks,
> 
> --John
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr