[103244] in North American Network Operators' Group
L3VPN VPNv4 NLRI - Route Reflector Scaling
daemon@ATHENA.MIT.EDU (Mark Tinka)
Sun Mar 23 21:53:14 2008
From: Mark Tinka <mtinka@globaltransit.net>
Reply-To: mtinka@globaltransit.net
To: nanog@nanog.org
Date: Mon, 24 Mar 2008 09:52:12 +0800
Errors-To: owner-nanog@merit.edu
--nextPart3178789.t3zYtSoWJS
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hello all.
(posted to C-NSP too; please excuse the length of the=20
message)
Considering the scaling techniques currently available for=20
VPNv4/L3VPN deployments as regards MP-BGP route reflectors,=20
what do folk think is currently the most elegant way to=20
deploy this that provides an even compromise on=20
manageability, cost and scale (see RFC 1925, section 2,=20
part 7, :-))?
While ORF and BGP RR groups are a logical way to go, they=20
require significant maintenance and might introduce scaling=20
issues as regards management on PE routers.
To mitigate this, however, outbound filters on the route=20
reflectors, to each PE router, may be used to propagate=20
VPNv4 NLRI to the PE routers that actually need them, but=20
introduces problems if this information has to traverse=20
regional or international PoP's where route reflectors talk=20
to other route reflectors (numerous RR clusters, perhaps)=20
before the end-PE router is reached. If filtering outbound=20
on the route reflectors were the network-wide policy,=20
having to co-ordinate filters on 10's of route reflectors=20
would be an administrative issue.
One other option we theorize would be to have dedicated=20
VPNv4 route reflectors (route reflectors that do not=20
reflect other address families, e.g., IPv4, IPv6, e.t.c.).=20
However, if PE routers are also used as general edge=20
routers (in the global routing table), the amount of=20
peering could become significant depending on the scale of=20
the network, and trying to co-ordinate the numerous route=20
reflectors serving the various address families could=20
become an issue when considered from a multi-PoP point of=20
view. Needless to say, adding route reflectors dedicated to=20
VPNv4 (or a single address family, for that matter) would=20
increase one's cost some.
On the otherhand, PE-to-PE MP-iBGP peering means outbound=20
filtering can easily be done toward a particular end-PE,=20
but the scaling issues of a full-mesh iBGP solution come=20
into play. We currently do not see a feasible way to=20
selectively filter outbound VPNv4 NLRI from the ingress PE=20
routers without causing reachability issues unless the=20
end-PE router is also the route reflector. This means route=20
reflectors would still have to carry network-wide VPNv4=20
NLRI, and would need to be the network elements that have=20
to figure out to which PE routers what VPNv4 NLRI should be=20
announced.
Using partitioned RR's is also a consideration; but the=20
administrative burden of co-ordinating which L3VPN has=20
their VPNv4 NLRI on which route reflector in what part of=20
the network could get problematic as more customers are=20
signed on.
One may also reduce the number of route reflectors to solve=20
this problem, but the risk of more remote PoP's depending=20
on centralized, far far away route reflectors is too=20
great - and then there's the CPU/memory resource thing...
My ideal scenario would be to somehow, scalably have the=20
ingress PE router inform the route reflector on which=20
end-PE routers actually need to receive the VPNv4 NLRI so=20
that the decision of the route reflector to do this is=20
somehow influenced by the ingress PE router, through some=20
kind of capability. ORF achieves this to some extent, but=20
requires the egress PE routers (and/or route reflectors) be=20
configured with the appropriate filters. Obviously, this is=20
probably not a thoroughly well-thought out=20
implementation :-).
How are folk handling these issues today?
Cheers,
Mark.
--nextPart3178789.t3zYtSoWJS
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
iQIVAwUAR+cJTGcZuYTeKm+GAQLcVhAAgwhPSKrYmPgE32XzYnP7mSB9aW9GBN1K
VTtqboD+dZMU/i0ev5+ahyhZq2FnSm718mbyEd2aonZFkERVSUadI6TgiFguCe6Q
F2ix71a0sEmOSm7AGph6rtZZk5hhmt4/hpYD4Po7cZaofey4MKbhtGPnahIkOmeZ
HgC/76BaTYPoCdzDou/fAmXEtbujJQmfejDgMtHc9Rzg9GK/DAe0OdhMNIn91JfS
yauJZ7qnyqyA+FHSn5y6k5nMkt1OoAoNWUTURDO9wpYuNNJtU7SvPNW00RzyuNOK
0O1H8P6f8d1UgAqb3LHw12m1c1xOB00f8lwqWyX4/xZ41PQRGPGPjzi2f36JekVE
DO+RqB0GtfI8yM1oNSOeWGH7uMSrTI8BFxTiq7wFaaJBFRzxyGSHQNskpi/I6lbN
bPemoI3IYFnO6kfrLWVXnC1dXE3vtfuHG2hIPe+sG/J+zkxYiphZq7imoqfgRmEI
bsA1zSRYQwiUfFAwKwL3MHKMECgG+7uXq9C4+vUN9K/2lgEoxwn6Ts/NL5Rvws7z
qoqWkQIX4Wo17bE9kifDcMXlJG8UG+Jp+qS3MkM4m3GDoPOsv9It99v+sGrU8t8X
e/dazBMw2aDTF6bYsaE7mMUePaqxyjK8gvlSMuxzy4O66+Z0NpX9Ko/5KTMfCSn4
rcd2XjFE3ww=
=5PuF
-----END PGP SIGNATURE-----
--nextPart3178789.t3zYtSoWJS--
