RRG Nov 08 Mapped BGP Paul Francis, Cornell Xiaohu Xu, Huawei Hitesh Ballani, Cornell

What is Mapped BGP? A BGP-based routing scalability solution Tries to minimize changes to BGP Focus on processing efficiency and inter-domain traffic engineering Not on RIB reduction per se, though better aggregation is enabled No changes to the edge

Mapped-BGP is Map-&-Encap Maps are distributed via BGP...but in a way that reduces BGP load....and maintains BGP’s “operational model” Litmus test: Mapped-BGP operates out of a legacy BGP configuration, but is more efficient

No RIB Reduction????? Scalability has a number of aspects: Storage Processing Convergence Time

No RIB Reduction????? Scalability has a number of aspects: Storage Processing RIB Storage FIB Storage Update rate Update cost X Convergence Time

RIB Storage FIB Storage Update Cost Update Rate If we shrink this Typical approach Convergence

RIB Storage FIB Storage Update Cost Update Rate If we shrink this Typical approach Convergence Then we’ll shrink these too Then these will shrink too (and we don’t need to worry about these)

RIB Storage FIB Storage Update Cost Update Rate Mapped-BGP Convergence Virtual Aggregation shrinks this

RIB Storage FIB Storage Update Cost Update Rate Mapped-BGP Convergence So probably we don’t need to fix this

RIB Storage FIB Storage Update Cost Update Rate Mapped-BGP Convergence So probably we don’t need to fix this But then this will be large

RIB Storage FIB Storage Update Cost Update Rate Mapped-BGP Convergence So Mapped-BGP shrinks this So probably we don’t need to fix this But then this will be large (and this)

RIB Storage FIB Storage Update Cost Update Rate Mapped-BGP Convergence Mapped-BGP also enables better aggregation, but requires managed address assignment (i.e. metro addresses)

Shrinking Update Cost Update less expensive if not installed into the FIB Maps are “policy free” (almost) Most updates are maps, not routes

Mapped-BGP: Three New Attributes Map: Action (add/delete), Tunnel Endpoint (TE), Prefix, Tunnel Endpoint Discriminator (TED) Split: Downstream AS, Upstream AS, Tunnel Endpoint Discriminator (TED) VP: Flag (is or is not a Virtual Prefix)

Mapped-BGP: New RIB Map-RIB: Map-RIB-in Map-RIB-out Other BGP RIBs are unchanged Can compress out #peers factor

Mapped-BGP: Three New Attributes Map: Action (add/delete), Tunnel Endpoint (TE), Prefix, Tunnel Endpoint Discriminator (TED) Split: Downstream AS, Upstream AS, Tunnel Endpoint Discriminator (TED) VP: Flag (is or is not a Virtual Prefix) Start by looking at basic map&encap

Pa=20.1/16 Pb=20.2/16 Pc=20.3/16 Pc=30.1/16 TEw= /28 Pw-agg=20.0/14

Pa=20.1/16 Pb=20.2/16 Pc=20.3/16 Pc=30.1/16 TEw= /28 Pw-agg=20.0/14 Tunnel Endpoints (TE) are anycasted across all routers in the AS. A TE is not (usually) a single address, but a CIDR block of addresses (i.e. TEw= /28)

Pa=20.1/16 Pb=20.2/16 Pc=20.3/16 Pc=30.1/16 TEw= /28 Pw-agg=20.0/14 W advertises: Route: AS-path=(W), NLRI=( /28) Map: TE=( /28), AT=(,, )

Pa=20.1/16 Pb=20.2/16 Pc=20.3/16 Pc=30.1/16 TEw= /28 Pw-agg=20.0/14 W advertises: Route: AS-path=(W), NLRI=(TEw) Map: TE=(TEw), AT=(,, )

Pa=20.1/16 Pb=20.2/16 Pc=20.3/16 Pc=30.1/16 TEw= /28 Pw-agg=20.0/14 W advertises: Route: AS-path=(W), NLRI=(TEw) Map: TE=(TEw), AT=(,, ) X advertises: Route: AS-path=(W,X), NLRI=(TEw) Map: TE=(TEw), AT=(,, ) From X, the route changes but not the map

Pa=20.1/16 Pb=20.2/16 Pc=20.3/16 Pc=30.1/16 TEw= /28 Pw-agg=20.0/14 Route: AS-path=(W), NLRI=(TEw) Map: TE=(TEw), AT=(,, ) route+map can be transposed as: Route: AS-path=(W), NLRI=(TEw, Pw-agg, Pd, Pa)

Route+Map  Route Transformation Policy applied to route extends to map entries Easy to compose reachability updates for legacy ASes BGP security stays the same Since most prefixes are maps, far fewer route policy decisions

Pa=20.1/16 Pb=20.2/16 Pc=20.3/16 Pc=30.1/16 TEw= /28 Pw-agg=20.0/14 A  W goes down: Map: TE=TEw, AT=( ) A  W comes up: Map: TE=TEw, AT=( ) Edge churn requires only map changes, not route changes

AS may receive different maps from different peers (during churn) Always converges to latest map Use map received from next- hop to tunnel endpoint Which map is used??? Rule: Still need to prove this.... Map advertised by each peer must be remembered

Map convergence is fast Don’t need to wait for best-path or other policy decision, IGP convergence, load balancing decision, etc. Maps can be propagated before they are fully processed Once validated, they can be passed on

If maps inherit TE-route policies, haven’t we lost policy granularity? But for Prefix-level policies, yes! For AS-level policies, no This is mostly load-balancing policies Prefer customer routes, don’t export routes from peers,....

Mapped-BGP: Three New Attributes Map: Action (add/delete), Tunnel Endpoint (TE), Prefix, Tunnel Endpoint Discriminator (TED) Split: Downstream AS, Upstream AS, Tunnel Endpoint Discriminator (TED) VP: Flag (is or is not a Virtual Prefix) Next lets look at inter- ISP traffic engineering

Mapped-BGP has two inter-domain Traffic Engineering mechanisms: One for multi-homed customer ISPs One for multi-homed sites

Pa=20.1/16 Pb=20.2/16 Pc=20.3/16 Pc=30.1/16 TEw= /28 Pw-agg=20.0/14 X receives: From W: Route: AS-path=(W), NLRI=(TEw) From W: Map: TE=(TEw), AT=(.... ) From I: Route: AS-path=(Z,I), NLRI=(TEz) From I: Map: TE=(TEz), AT=(.... ) Pa is reachable via two tunnels TEDs indicate A’s preference But X chooses tunnel(s)

Different ISP’s traffic engineering requirements may be in conflict Mapped-BGP lets receivers indicate load preference but lets senders make the choice (on a router-by-router basis)

TED is a parameter-less value At receiving AS: 1. Set TED values 2. Measure resulting load (days or weeks) 3. Tweak TED values, go to (2) At sending AS: 1. Satisfy own Traffic Engineering needs 2. If possible, honor TED values

Pa=20.1/16 Pb=20.2/16 Pc=20.3/16 Pc=30.1/16 TEw= /28 Pw-agg=20.0/14 W does load balance by “splitting” its TE: Route To X: AS=(W), NLRI=(TEwx= /29) Route To Y: AS=(W), NLRI=(TEwy= /29) Map: TE=(TEw), AT=(,, ) Split: DS-AS=W, US-AS=(, ) /28 TE-route is split into two /29 TE-routes Each route is given a TED

From Y: Route: AS=(W,Y), NLRI=(TEwx) From X: Route: AS=(W,X), NLRI=(TEwy) Route: AS=(Z,I,X), NLRI=(TEz) Map: TE=(TEz), AT=( ) From X and Y: Map: TE=(TEw), AT=(,, ) Split: DS-AS=W, US-AS=(, ) AS J receives the following:

From Y: Route: AS=(W,Y), NLRI=(TEwx) From X: Route: AS=(W,X), NLRI=(TEwy) Route: AS=(Z,I,X), NLRI=(TEz) Map: TE=(TEz), AT=( ) From X and Y: Map: TE=(TEw), AT=(,, ) Split: DS-AS=W, US-AS=(, ) First J decides how to split traffic to AS A

From Y: Route: AS=(W,Y), NLRI=(TEwx) From X: Route: AS=(W,X), NLRI=(TEwy) Route: AS=(Z,I,X), NLRI=(TEz) Map: TE=(TEz), AT=( ) From X and Y: Map: TE=(TEw), AT=(,, ) Split: DS-AS=W, US-AS=(, ) Then J decides how to split traffic tunneled to W

From Y: Route: AS=(W,Y), NLRI=(TEwx) From X: Route: AS=(W,X), NLRI=(TEwy) Route: AS=(Z,I,X), NLRI=(TEz) Map: TE=(TEz), AT=( ) From X and Y: Map: TE=(TEw), AT=(,, ) Split: DS-AS=W, US-AS=(, ) TEDs are efficient (One set of TEDs per balancing AS)

Mapped-BGP: Three New Attributes Map: Action (add/delete), Tunnel Endpoint (TE), Prefix, Tunnel Endpoint Discriminator (TED) Split: Downstream AS, Upstream AS, Tunnel Endpoint Discriminator (TED) VP: Flag (is or is not a Virtual Prefix) Finally lets look at aggregation

Tunnels let us create a virtual topology Every router receives every map We show how to relax this later Any router can define a “virtual prefix” (VP), and FIB-install maps for all sub- prefixes within the VP This router is an “aggregation point router” (AP-router) for the VP VP is bigger than any real sub-prefix

An AP-router originates a route to the VP The “VP flag” attribute is attached to the route This tells other routers that the originator can route to all sub-prefixes Tunnels let us create a virtual topology

The router can FIB-suppress all but 1/8 Say a router receives these routes: AS-path=(W,X,Y), NLRI=(1.1/16, 1.3/16, 1.5/16) AS-path=(A,B,C), NLRI=(1.2/16, 1.4/16, 1.6/16) AS-path=(I,J,K), VP-attr, NLRI=(1/8) The VP-attribute essentially lets routers “violate” best-match selection! Unless careful, this leads to overly long paths

Metro Addresses with VPs Metro addressing generally regarded as a solution to the site multi-homing problem Problem is that we lack regulatory mechanisms to insure rich physical topology within metro area VP-attribute relaxes need for this physical topology

Metro Addresses with VPs Metro address prefix is a VP Routers in the metro-area are configured as AP-routers for the VP Only transit ISPs advertise VP Prevents lower-tier ISPs from becoming transits for non-customers

path with metro addressing path without metro addressing

Failures result in longer paths, not unreachability

VPs can lead to reduced RIB size Metro VPs work as long as all AP- routers know of all sub-prefixes Define “AS-group” = “ASes participating in given metro” If AS-group has rich enough connectivity, sub-prefixes don’t need to be advertised outside of AS-group

VPs can lead to transient loops

Until unreachability info reaches other AS, packets will loop through tunnels

Solution to transient tunnel loops: Routers need to know when a packet has arrived via a tunnel If packet can’t be locally delivered, drop packet Details in draft

Questions, discussion, etc.....