Download presentation
Presentation is loading. Please wait.
Published byAbraham Floyd Modified over 9 years ago
1
RRG Nov 08 Mapped BGP Paul Francis, Cornell Xiaohu Xu, Huawei Hitesh Ballani, Cornell
2
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
3
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
4
No RIB Reduction????? Scalability has a number of aspects: Storage Processing Convergence Time
5
No RIB Reduction????? Scalability has a number of aspects: Storage Processing RIB Storage FIB Storage Update rate Update cost X Convergence Time
6
RIB Storage FIB Storage Update Cost Update Rate If we shrink this Typical approach Convergence
7
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)
8
RIB Storage FIB Storage Update Cost Update Rate Mapped-BGP Convergence Virtual Aggregation shrinks this
9
RIB Storage FIB Storage Update Cost Update Rate Mapped-BGP Convergence So probably we don’t need to fix this
10
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
11
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)
12
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)
13
Shrinking Update Cost Update less expensive if not installed into the FIB Maps are “policy free” (almost) Most updates are maps, not routes
14
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)
15
Mapped-BGP: New RIB Map-RIB: Map-RIB-in Map-RIB-out Other BGP RIBs are unchanged Can compress out #peers factor
16
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
17
Pa=20.1/16 Pb=20.2/16 Pc=20.3/16 Pc=30.1/16 TEw=40.1.1.0/28 Pw-agg=20.0/14
18
Pa=20.1/16 Pb=20.2/16 Pc=20.3/16 Pc=30.1/16 TEw=40.1.1.0/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=40.1.1.0/28)
19
Pa=20.1/16 Pb=20.2/16 Pc=20.3/16 Pc=30.1/16 TEw=40.1.1.0/28 Pw-agg=20.0/14 W advertises: Route: AS-path=(W), NLRI=(40.1.1.0/28) Map: TE=(40.1.1.0/28), AT=(,, )
20
Pa=20.1/16 Pb=20.2/16 Pc=20.3/16 Pc=30.1/16 TEw=40.1.1.0/28 Pw-agg=20.0/14 W advertises: Route: AS-path=(W), NLRI=(TEw) Map: TE=(TEw), AT=(,, )
21
Pa=20.1/16 Pb=20.2/16 Pc=20.3/16 Pc=30.1/16 TEw=40.1.1.0/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
22
Pa=20.1/16 Pb=20.2/16 Pc=20.3/16 Pc=30.1/16 TEw=40.1.1.0/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)
23
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
24
Pa=20.1/16 Pb=20.2/16 Pc=20.3/16 Pc=30.1/16 TEw=40.1.1.0/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
25
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
26
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
27
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,....
28
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
29
Mapped-BGP has two inter-domain Traffic Engineering mechanisms: One for multi-homed customer ISPs One for multi-homed sites
30
Pa=20.1/16 Pb=20.2/16 Pc=20.3/16 Pc=30.1/16 TEw=40.1.1.0/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)
31
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)
32
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
33
Pa=20.1/16 Pb=20.2/16 Pc=20.3/16 Pc=30.1/16 TEw=40.1.1.0/28 Pw-agg=20.0/14 W does load balance by “splitting” its TE: Route To X: AS=(W), NLRI=(TEwx=40.1.1.0/29) Route To Y: AS=(W), NLRI=(TEwy=40.1.1.8/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
34
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:
35
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
36
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
37
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)
38
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
39
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
40
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
41
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
42
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
43
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
45
path with metro addressing path without metro addressing
47
Failures result in longer paths, not unreachability
48
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
49
VPs can lead to transient loops
50
Until unreachability info reaches other AS, packets will loop through tunnels
51
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
52
Questions, discussion, etc.....
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.