Danny,
I already pointed out that we have rt-constrain which based on pushing
RTs precisely addresses that problem in the context of VPNv4.
Note is works equally well for customer VPNs routes or for the Internet
routes in the VRFs.
Cheers,
R.
On Mar 26, 2009, at 12:27 PM, Robert Raszuk wrote:
Please note that tt is perfectly feasible not to reflect back to the
client for one AFI/SAFI and still reflect back for other AFI/SAFIs.
Sure, one could do that, I don't think I said anything to
the contrary.
If your main point complains about the change and permission to
reflect back PATHs to the client introduced by RFC 2796 in the scope
of the Internet let's drop even mentioning the ACCEPT_OWN as not
relevant to the topic.
No, it's as much (more?) of an issue in VPNv4 or other SAFIs.
A client will receive every best route it sends to RRs * the
number of RRs. Those updates have to be processed by the client
and discarded, and they're in the exact same processing path as
all other BGP updates from internal or external peers. If I
were running a VPN network I'd prefer that the client spend it's
time and cycles chewing on useful updates, not useless updates.
Also note that MANY IP/VPN deployments use the same routers
for VPNs and Internet, and most implementations today don't
discriminate update processing per AF.
-danny
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
