Mark Tinka
2008-03-24 01:52:12 UTC
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.
(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.