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

["Jim Guichard (jguichar)" <jguichar at cisco.com>]

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 at ietf.org [mailto:idr-bounces at ietf.org] On Behalf Of
John
> G. Scudder
> Sent: Tuesday, May 06, 2008 10:40 AM
> To: Jeffrey Haas
> Cc: idr at 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 at ietf.org
> https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr