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

["John G. Scudder" <jgs at juniper.net>]

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