[c-nsp] L3VPN VPNv4 NLRI - Route Reflector Scaling

[Mark Tinka]

Hello all.

(posted to NANOG 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part.
Url : https://puck.nether.net/pipermail/cisco-nsp/attachments/20080324/5b7f49cc/attachment.bin