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

"John G. Scudder" <jgs@juniper.net> Tue, 06 May 2008 14:40 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 0FB843A7038; Tue, 6 May 2008 07:40:33 -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 BE3823A7038 for <idr@core3.amsl.com>; Tue, 6 May 2008 07:40:31 -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=[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 fYnochBz3QVt for <idr@core3.amsl.com>; Tue, 6 May 2008 07:40:30 -0700 (PDT)
Received: from chip3og56.obsmtp.com (chip3og56.obsmtp.com [64.18.14.177]) by core3.amsl.com (Postfix) with ESMTP id A9C3F3A7036 for <idr@ietf.org>; Tue, 6 May 2008 07:40:30 -0700 (PDT)
Received: from source ([66.129.224.36]) by chip3ob56.postini.com ([64.18.6.12]) with SMTP; Tue, 06 May 2008 07:40:26 PDT
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 May 2008 07:40:26 -0700
Received: from [172.16.13.201] ([172.16.13.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m46EePx39218; Tue, 6 May 2008 07:40:25 -0700 (PDT) (envelope-from jgs@juniper.net)
Message-Id: <046A97A5-D1A9-4576-A961-0E4DE1DFEB0D@juniper.net>
From: "John G. Scudder" <jgs@juniper.net>
To: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <20080506111523.GA9122@scc.mi.org>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Tue, 06 May 2008 10:40:25 -0400
References: <A1F50CB516D211409DFD05D6B3CE6D300ED2856E@KCCLUST06EVS1.ugd.att.com> <20080506111523.GA9122@scc.mi.org>
X-Mailer: Apple Mail (2.919.2)
X-OriginalArrivalTime: 06 May 2008 14:40:26.0895 (UTC) FILETIME=[1FCBB9F0:01C8AF87]
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

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