*

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

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.