Constrained VPN route distribution

1. Constrained VPN route distribution Pedro Marques roque@juniper.net Robert Raszuk rraszuk@cisco.com Ron Bonica ronald.p.bonica@wcom.com Luyuan Fang luyuanfang@att.com

2. PE-1 PE-3 RR1 RR2 PE-2 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.

3. Increasing complexity Canada UK APAC US Europe • Networks have administrative boundaries. • AS per country is common. • Route distribution layer (RRs, ASBRs) grows… • VPN locality tends to increase.

4. 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.

5. RR1-plane 1 PE-1 PE-2 RR1-plane 2 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.

6. 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.

7. PE-1 PE-3 RR1 RR2 PE-2 Constrained route distribution Import: RT:a, RT:b • Tradeoff: advertise import RTs instead of all VPN routes. • Advertise VPN on inverse direction of RT advertisement that imports VPN route. a, b, c Import: RT:c, RT:d c, d Import: RT:a, RT:c

8. Inter-AS Propagation B A C E D • 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>

9. 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.

10. 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.

11. PE-1 PE-M RR-1 PE-N RR-2 Deployment • Can complement the current approaches that where discussed previously. • Or: RR mesh • Assumption: average number routes per VPN can be calculated. • Introduce new RR into the mesh when needed.

12. 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.