Hello all. (posted to C-NSP too; please excuse the length of the message) Considering the scaling techniques currently available for VPNv4/L3VPN deployments as regards MP-BGP route reflectors, what do folk think is currently the most elegant way to deploy this that provides an even compromise on manageability, cost and scale (see RFC 1925, section 2, part 7, :-))? While ORF and BGP RR groups are a logical way to go, they require significant maintenance and might introduce scaling issues as regards management on PE routers. To mitigate this, however, outbound filters on the route reflectors, to each PE router, may be used to propagate VPNv4 NLRI to the PE routers that actually need them, but introduces problems if this information has to traverse regional or international PoP's where route reflectors talk to other route reflectors (numerous RR clusters, perhaps) before the end-PE router is reached. If filtering outbound on the route reflectors were the network-wide policy, having to co-ordinate filters on 10's of route reflectors would be an administrative issue. One other option we theorize would be to have dedicated VPNv4 route reflectors (route reflectors that do not reflect other address families, e.g., IPv4, IPv6, e.t.c.). However, if PE routers are also used as general edge routers (in the global routing table), the amount of peering could become significant depending on the scale of the network, and trying to co-ordinate the numerous route reflectors serving the various address families could become an issue when considered from a multi-PoP point of view. Needless to say, adding route reflectors dedicated to VPNv4 (or a single address family, for that matter) would increase one's cost some. On the otherhand, PE-to-PE MP-iBGP peering means outbound filtering can easily be done toward a particular end-PE, but the scaling issues of a full-mesh iBGP solution come into play. We currently do not see a feasible way to selectively filter outbound VPNv4 NLRI from the ingress PE routers without causing reachability issues unless the end-PE router is also the route reflector. This means route reflectors would still have to carry network-wide VPNv4 NLRI, and would need to be the network elements that have to figure out to which PE routers what VPNv4 NLRI should be announced. Using partitioned RR's is also a consideration; but the administrative burden of co-ordinating which L3VPN has their VPNv4 NLRI on which route reflector in what part of the network could get problematic as more customers are signed on. One may also reduce the number of route reflectors to solve this problem, but the risk of more remote PoP's depending on centralized, far far away route reflectors is too great - and then there's the CPU/memory resource thing... My ideal scenario would be to somehow, scalably have the ingress PE router inform the route reflector on which end-PE routers actually need to receive the VPNv4 NLRI so that the decision of the route reflector to do this is somehow influenced by the ingress PE router, through some kind of capability. ORF achieves this to some extent, but requires the egress PE routers (and/or route reflectors) be configured with the appropriate filters. Obviously, this is probably not a thoroughly well-thought out implementation :-). How are folk handling these issues today? Cheers, Mark.