* Constrained VPN route distribution Pedro Marques Robert Raszuk Ron Bonica
-
Upload
bethanie-obrien -
Category
Documents
-
view
212 -
download
0
description
Transcript of * Constrained VPN route distribution Pedro Marques Robert Raszuk Ron Bonica
*
Constrained VPN route distribution
Pedro Marques [email protected]
Robert Raszuk [email protected]
Ron Bonica [email protected]
Luyuan Fang [email protected]
Problem statement
VPN route distribution layer (route reflectors) carry all route for all VPNs.
Assumption: Some VPNs are local to RR-1 cluster.
Goal: reduce the number of routes on the RRs by taking advantage of locality.
RR1
PE-2
PE-1PE-3
RR2
Increasing complexity
Networks have administrative boundaries. AS per country is common. Route distribution layer (RRs, ASBRs) grows… VPN locality tends to increase.
USUSAPACAPAC
UKUK
EuropeEurope
CanadaCanada
Current approaches Network management:
“Provisioning system problem”. Tag routes with communities; filter on boundaries. Catch 1: combinatorial problem of number of
“regions” (AS granularity or RR-cluster granularity). Catch 2: if each SP has develop its own tools, not the
lowest cost solution. Split the network in different planes.
Forget locality; each plane takes a share of the load. There is an added cost in managing multiple planes.
Multiple planes
Split the VPN routes among different planes.
Good solution if there is no locality. Actually: orthogonal with locality problem. High cost on SP to interconnect N planes
with multiple ASes.
PE-1 PE-2
RR1-plane 1
RR1-plane 2
Extended Community ORF 2547bis document suggests RT ORF for
this purpose. Database exchange of RT entries in
REFRESH messages. Point-to-point mechanism. Not applicable between RRs since
information advertisements would loop.
Constrained route distribution
Tradeoff: advertise import RTs instead of all VPN routes.
Advertise VPN on inverse direction of RT advertisement that imports VPN route.
RR1
PE-2
PE-1PE-3
RR2
Import: RT:a, RT:bImport: RT:a, RT:b
Import: RT:a, RT:cImport: RT:a, RT:c
Import: RT:c, RT:dImport: RT:c, RT:d
a, b, ca, b, c
c, dc, d
Inter-AS Propagation
For a given Route Target membership is: Case 1: {A, D} Case 2: {A, D, E}
How does C distinguish between the two cases ? NLRI: <RT:as#>; e.g.: <RT:A> and <RT:F>
AA
BB
DD
CC
EE
Intra-AS Plan a)
same trick: Source a <RT:PE-loopback> NLRI. Can do better:
PE sources <RT:local-as#> NLRI. RR reflects PE routes to distribution mesh. RR advertises <RT:local-as#> to clients.
RT NLRI vs ORF Use BGP UPDATE messages rather than
REFRESH for RT database exchange. Allows for code reuse of db exchange
mecanisms. REFRESH has different semantics with ORF. ORF implies implementation of scalable
filtering from RR to PE. Modern BGP implementation:
AF independent DB-exchange protocol. Per AF encoding/decoding rules.
RT NLRI uses existing wheel.
Deployment Can complement the current approaches that
where discussed previously. Or:
PE-1
PE-M
RR-1
PE-N
RR-2
Assumption: average number routes per VPN can be calculated.
Introduce new RR into the mesh when needed.
RRmesh
Summary Increases usefulness of RT ORF. Implementation:
RT-based outbound filtering: same as ORF. RT database exchange: simpler; within existing
BGP framework when compared with ORF. Assumption: locality of VPN membership. Orthogonal with mechanisms that assume
no locality. Security: proposed mechanism MAY
restrict route advertisements. Does not cause extra route advertisements.