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

["UTTARO, JAMES, ATTLABS" <uttaro at att.com>]

Comments In-Line.. 

-----Original Message-----
From: Jeffrey Haas [mailto:jhaas at pfrc.org] 
Sent: Tuesday, May 06, 2008 2:00 PM
To: John G. Scudder; Jim Guichard (jguichar)
Cc: Jeffrey Haas; UTTARO, JAMES, ATTLABS; idr at 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 at ietf.org
https://www.ietf.org/mailman/listinfo/idr