Interdomain Routing and the Interdomain Routing and the Border Gateway Protocol (BGP)—Border Gateway Protocol (BGP)—

What does it all mean? What does it all mean?

IMAMinneapolis

April 6, 2003

Timothy G. Griffin AT&T Research

griffin@research.att.com

http://www.research.att.com/~griffin

http://www.research.att.com/~griffin/interdomain.html

Outline

Part I: The glue that holds the Internet together : interdomain routing with The Border Gateway Protocol (BGP)

Part II: A formal model of BGP routing policies Joint work with Gordon Wilfong and F. Bruce Shepherd, Bell Labs

Charlotte

Portland

Providence

Newark

Cedar Knolls

Syracuse

Buffalo

White Plains

Rochester

Columbia

New Orleans

Nashville

Austin

Houston

TulsaOklahom

aCity

Albuquerque

Phoenix

AnaheimAnaheim

Las Vegas

Salt LakeCity

ColoradoSprings

Milwaukee

Detroit

Columbus

Cincinnati

Seattle Spokane

Portland

Louisville

Little Rock

Jacksonville

Ft. Lauderdale

Miami

Raleigh

Richmond

DenverIndianapolis

Pittsburgh

Baltimore

Plymouth

Atlanta

Minneapolis

Gardena

Tampa

SanBernardino

Arlington

Ft. Worth

Rochelle Pk

Honolulu

Orlando

Sherman Oaks

Ojus

Hamilton SquareSilver

Springs

Wayne

Chicago

RollingMeadows

Omaha

St Louis

San Diego

Anchorage, AK

N X OC48

Backbone Node

Gateway Node

N X DS3N X OC3

Remote Access Router

R Remote GSR Access Router

N X OC12

NX OC192

Cambridge

Framingham

StamfordBridgeport

Grand Rapids Providence

Glenview

Albany

Sacramento

Oakland

Redwood City

San Jose

San Francisco

ChicagoSan Francisco

Florissant

Davenport

Worcester

Madison

Camden, NJ

Norcross

New Brunswick

Birmingham

San Antonio

Oak Brook

South Bend

Dayton

Bohemia

Hartford

San Juan PR

W. Palm Beach

HarrisburgDes Moines

Memphis

Greensboro

Norfolk

R

KansasCity

AkronRR

R

Los Angeles

Dallas

Wash.DC

St. Paul

Freehold

R

Manchester

R

R

RFt.

Lauderdale

Dunwoody

Note: Connectivity and nodes shown are targeted for deployment; actual deployment

may vary. Maps should not be used to predict service availability.

R

R

R

Phil

NYC

Cleveland

R

RNYC-Bdwy

Birmingham

LA-Airport Blvd

AT&T IP BackboneYear end 2001

Rev. 6-4-01

(Winter '02)

(Win

ter '0

2)

(Summer '03)

UW-Superior

UW-StoutUW-River Falls

Fox Valley TC

UW-Oshkosh

UW-Milwaukee

UW-ParksideUW-Whitewater

UW-Madison

UW-Platteville

UW-La Crosse

UW-Eau Claire

UW-Stevens Point

UW-Green Bay

Marshfield

Rhinelander

Rice Lake

Clintonville

StilesJct.

Portage

Dodgeville

La Crosse

Genuity

OC-3 (155Mbps)

DS-3 (45Mbps)

T1 (1.5Mbps)

OC-12 (622Mbps)

(Summer '02)

Qwestand Other

Provider(s)

(Summ

er '02)

Internet 2& Qwest

Peering - Public and Private Commodity Internet Transit Internet2 Merit and Other State Networks National Education Network Regional Research Peers

Wausau

Gigabit Ethernet

(Summer '02)

(Sum

mer '03)

Chicago - 1

Chicago - 2(Winter '02)

Chicago

wiscnet.net

GO BUCKY!

Telstra international

WorldCom (UUNet)

Network Interconnections

• Exchange Point– Layer 2 or Layer 3

• Private Circuit– May be provided by a

third party

8

What about Logical Connectivity?

Physical 1

Network

DataLink 1

Transport

Application

Session

Presentation

Network

Physical 1

DataLink 1

Physical 2

DataLink 2

Router

Physical 2

Network

DataLink 2

Transport

Application

Session

Presentation

Medium 1 Medium 2

Separate physical networks glued together into one logical network

9

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL | Service Type | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

All Hail the IP Datagram!

HEADER

DATA

1981, RFC 791

... up to 65,515 octets of data ...

::|+|+|

::|+|+|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

shaded fields little-used today

10

Hosts, Networks, and Routers

Network A

Network B Network CRouter

Host 1

Host 2

Host 7

Host 1

Host 12 Host 2

Unique IP Address = Network Number + Host Number

11

Actually, IP addresses Identify Interfaces

Network A

Network B Network C

Host 1

Host 2

Host 7

Host 1

Host 12 Host 2

Network C, Host 3

Network A, Host 3

Network B, Host 77

Machines can have more than one IP address.All routers do!

12

IP Forwarding Table

Destination Next Hop Interface

Net ANet BNet C, Host 3

Router 1DirectRouter 2Router 1

INT 7

INT 7INT 3INT 4

A destination is usuallya network. May also be a host, or a “gateway of last resort” (default)

The next hop is either a directlyconnected network or a router on a directly connected network

A physical interface

Net C

13

IP Forwarding Process

Forwarding Process

IP Forwarding Table Router

1. Remove a packet from an input queue

3. Match packet’s destination to a table entry

2. Check for sanity, decrement TTL field

4. Place packet on correct output queue

If queuesget full, just

drop packets!

If queuesget full, just

drop packets!

14

Routing vs. Forwarding

R

R

RA

B

C

D

R1

R2

R3

R4 R5

ENet Nxt Hop

R4R3R3R4DirectR4

Net Nxt Hop

A B C D Edefault

R2R2DirectR5R5R2

Net Nxt Hop

A B C D Edefault

R1DirectR3R1R3R1

Default toupstreamrouter

A B C D Edefault

Forwarding: determine next hop

Routing: establish end-to-end paths

Forwarding always works

Routing can be badly broken

15

How Are Forwarding Tables Populated to implement

Routing?Statically Dynamically

Routers exchange network reachability information using ROUTING PROTOCOLS. Routers use this to compute best routes

Administrator manually configuresforwarding table entries

In practice : a mix of these.Static routing mostly at the “edge”

+ More control+ Not restricted to destination-based forwarding - Doesn’t scale- Slow to adapt to network failures

+ Can rapidly adapt to changes in network topology+ Can be made to scale well- Complex distributed algorithms- Consume CPU, Bandwidth, Memory- Debugging can be difficult- Current protocols are destination-based

Routers Talking to Routers(The “control plane”)

Routing info

Routing info

• Routing computation is distributed among routers within a routing domain

• Computation of best next hop based on routing information is the most CPU/memory intensive task on a router

• Routing messages are usually not routed, but exchanged via layer 2 between physically adjacent routers (internal BGP and multi-hop external BGP are exceptions)

Architecture of Dynamic Routing

AS 1

AS 2

BGP

EGP = Exterior Gateway Protocol

IGP = Interior Gateway Protocol

Metric based: OSPF, IS-IS, RIP, EIGRP (cisco)

Policy based: BGP

The Routing Domain of BGP is the entire Internet

OSPF

EIGRP

• Topology information is flooded within the routing domain

• Best end-to-end paths are computed locally at each router.

• Best end-to-end paths determine next-hops.

• Based on minimizing some notion of distance

• Works only if policy is shared and uniform

• Examples: OSPF, IS-IS

• Each router knows little about network topology

• Only best next-hops are chosen by each router for each destination network.

• Best end-to-end paths result from composition of all next-hop choices

• Does not require any notion of distance

• Does not require uniform policies at all routers

• Examples: RIP, BGP

Link State Vectoring

Technology of Distributed Routing

The Gang of Four

Link State Vectoring

EGP

IGP

BGP

RIPIS-IS

OSPF

20

Happy Packets: The Internet Does Not Exist Only to Populated Routing Tables

Forwarding Table

OSPFDomain

RIPDomain

BGPOSPF Process

OSPF Routing tables

RIP Process

RIP Routing tables

BGP Process

BGP Routing tables

Forwarding Table Manager

AS Numbers (ASNs)

64512 through 65535 are “private”

• Genuity: 1 • MIT: 3• Harvard: 11• Yale: 29 • UCLA: 52• AT&T: 7018, 5075, …, 6341, … • UUNET: 701, 702, 284, 12199, …• Sprint: 1239, 1240, 6211, 6242, …• …

ASNs represent units of routing policy

Currently over 14,000 in use.

Autonomous Routing Domains Don’t Always Need BGP or an ASN

Qwest

Yale University

Nail up default routes 0.0.0.0/0pointing to Qwest

Nail up routes 130.132.0.0/16pointing to Yale

130.132.0.0/16

Static routing is the most common way of connecting anautonomous routing domain to the Internet. This helps explain why BGP is a mystery to many …

U of Minnesota Neighborhood

AS 1Genuity

AS 57 UMN

AS 7018 AT&T

AS 3908SuperNet (Qwest)

AS 217 UMN

AS 1998 State of Minnesota

Sources: ARIN, Route Views, RIPE

128.101.0.0/16

www.ima.umn.edu 128.101.10.128 (DNS)

ASNs Can Be “Shared” (RFC 2270)

AS 701UUNet

ASN 7046 is assigned to UUNet. It is used byCustomers single homed to UUNet, but needing BGP for some reason (load balancing, etc..) [RFC 2270]

AS 7046Crestar Bank

AS 7046 NJIT

AS 7046HoodCollege

128.235.0.0/16

Number of Used ASNs

Source: Geoff Huston, http://bgp.potaroo.net

AS Graphs Can Be Fun

The subgraph showing all ASes that have more than 100 neighbors in fullgraph of 11,158 nodes. July 6, 2001. Point of view: AT&T route-server

AS Graph != Internet Topology

The AS graphmay look like this. Reality may be closer to this…

BGP was designed to throw away information!

Growth of BGP Routes

Source: Geoff Huston, http://bgp.potaroo.net, Nov. 3, 2002

Percentage of IPv4 space advertised

Customers and Providers

Customer pays provider for access to the Internet

provider

customer

IP trafficprovider customer

The Peering Relationship

peer peer

customerprovider

Peers provide transit between their respective customers

Peers do not provide transit between peers

Peers (often) do not exchange $$$trafficallowed

traffic NOTallowed

Peering Provides Shortcuts

Peering also allows connectivity betweenthe customers of “Tier 1” providers.

peer peer

customerprovider

32

BGP-4• BGP = Border Gateway Protocol

• Is a Policy-Based routing protocol

• Is the de facto EGP of today’s global Internet

• Relatively simple protocol, but configuration is complex and the

entire world can see, and be impacted by, your mistakes.

• 1989 : BGP-1 [RFC 1105]– Replacement for EGP (1984, RFC 904)

• 1990 : BGP-2 [RFC 1163]

• 1991 : BGP-3 [RFC 1267]

• 1995 : BGP-4 [RFC 1771] – Support for Classless Interdomain Routing (CIDR)

33

BGP Operations (Simplified) Establish session on TCP port 179

Exchange all active routes

Exchange incremental updates

AS1

AS2

While connection is ALIVE exchangeroute UPDATE messages

BGP session

34

Four Types of BGP Messages

• Open : Establish a peering session.

• Keep Alive : Handshake at regular intervals.

• Notification : Shuts down a peering session.

• Update : Announcing new routes or withdrawing previously announced routes.

announcement = prefix + attributes values

BGP Attributes

Value Code Reference----- --------------------------------- --------- 1 ORIGIN [RFC1771] 2 AS_PATH [RFC1771] 3 NEXT_HOP [RFC1771] 4 MULTI_EXIT_DISC [RFC1771] 5 LOCAL_PREF [RFC1771] 6 ATOMIC_AGGREGATE [RFC1771] 7 AGGREGATOR [RFC1771] 8 COMMUNITY [RFC1997] 9 ORIGINATOR_ID [RFC2796] 10 CLUSTER_LIST [RFC2796] 11 DPA [Chen] 12 ADVERTISER [RFC1863] 13 RCID_PATH / CLUSTER_ID [RFC1863] 14 MP_REACH_NLRI [RFC2283] 15 MP_UNREACH_NLRI [RFC2283] 16 EXTENDED COMMUNITIES [Rosen] ... 255 reserved for development

From IANA: http://www.iana.org/assignments/bgp-parameters

Mostimportantattributes

Not all attributesneed to be present inevery announcement

Attributes are Used to Select Best Routes

192.0.2.0/24pick me!

192.0.2.0/24pick me!

192.0.2.0/24pick me!

192.0.2.0/24pick me!

Given multipleroutes to the sameprefix, a BGP speakermust pick at mostone best route

(Note: it could reject them all!)

37

BGP Route Processing

Best Route Selection

Apply Import Policies

Best Route Table

Apply Export Policies

Install forwardingEntries for bestRoutes.

ReceiveBGPUpdates

BestRoutes

TransmitBGP Updates

Apply Policy =filter routes & tweak attributes

Based onAttributeValues

IP Forwarding Table

Apply Policy =filter routes & tweak attributes

Open ended programming.Constrained only by vendor configuration language

Route Selection Summary

Highest Local Preference

Shortest ASPATH

Lowest MED

i-BGP < e-BGP

Lowest IGP cost to BGP egress

Lowest router ID

traffic engineering

Enforce relationships

Throw up hands andbreak ties

Tweak Tweak Tweak

• For inbound traffic– Filter outbound routes– Tweak attributes on

outbound routes in the hope of influencing your neighbor’s best route selection

• For outbound traffic– Filter inbound routes– Tweak attributes on

inbound routes to influence best route selection

outboundroutes

inboundroutes

inboundtraffic

outboundtraffic

In general, an AS has morecontrol over outbound traffic

40

ASPATH Attribute

AS7018135.207.0.0/16AS Path = 6341

AS 1239Sprint

AS 1755Ebone

AT&T

AS 3549Global Crossing

135.207.0.0/16AS Path = 7018 6341

135.207.0.0/16AS Path = 3549 7018 6341

AS 6341

135.207.0.0/16

AT&T Research

Prefix Originated

AS 12654RIPE NCCRIS project

AS 1129Global Access

135.207.0.0/16AS Path = 7018 6341

135.207.0.0/16AS Path = 1239 7018 6341

135.207.0.0/16AS Path = 1755 1239 7018 6341

135.207.0.0/16AS Path = 1129 1755 1239 7018 6341

In fairness: could you do this “right” and still scale?

Exporting internalstate would dramatically increase global instability and amount of routingstate

Shorter Doesn’t Always Mean Shorter

AS 4

AS 3

AS 2

AS 1

Mr. BGP says that path 4 1 is better than path 3 2 1

Duh!

42

Shedding Inbound Traffic with ASPATH Padding Hack

Padding will (usually) force inbound traffic from AS 1to take primary link

AS 1

192.0.2.0/24ASPATH = 2 2 2

customerAS 2

provider

192.0.2.0/24

backupprimary

192.0.2.0/24ASPATH = 2

43

Padding May Not Shut Off All Traffic

AS 1

192.0.2.0/24ASPATH = 2 2 2 2 2 2 2 2 2 2 2 2 2 2

customerAS 2

provider

192.0.2.0/24

192.0.2.0/24ASPATH = 2

AS 3provider

AS 3 will sendtraffic on “backup”link because it prefers customer routes and localpreference is considered before ASPATH length!

Padding in this way is oftenused as a form of loadbalancing

backupprimary

44

COMMUNITY Attribute to the Rescue!

AS 1

customerAS 2

provider

192.0.2.0/24

192.0.2.0/24ASPATH = 2

AS 3provider

backupprimary

192.0.2.0/24ASPATH = 2 COMMUNITY = 3:70

Customer import policy at AS 3:If 3:90 in COMMUNITY then set local preference to 90If 3:80 in COMMUNITY then set local preference to 80If 3:70 in COMMUNITY then set local preference to 70

AS 3: normal customer local pref is 100,peer local pref is 90

45

Hot Potato Routing: Go for the Closest Egress Point 192.44.78.0/24

15 56 IGP distances

egress 1 egress 2

This Router has two BGP routes to 192.44.78.0/24.

Hot potato: get traffic off of your network as Soon as possible. Go for egress 1!

46

Getting Burned by the Hot Potato

15 56

172865High bandwidth

Provider backbone

Low bandwidthcustomer backbone

Heavy Content Web Farm

Many customers want their provider to carry the bits!

tiny http request

huge http reply

SFF NYC

San Diego

47

Cold Potato Routing with MEDs(Multi-Exit Discriminator Attribute)

15 56

172865

Heavy Content Web Farm

192.44.78.0/24

192.44.78.0/24MED = 15

192.44.78.0/24MED = 56

This means that MEDs must be considered BEFOREIGP distance!

Prefer lower MED values

Note1 : some providers will not listen to MEDs

Note2 : MEDs need not be tied to IGP distance

PART II

Policies Can Interact Strangely(“Route Pinning” Example)

backup

Disaster strikes primary linkand the backup takes over

Primary link is restored but sometraffic remains pinned to backup

1 2

3 4

Install backup link using community

customer

News at 11:00h

• BGP is not guaranteed to converge on a stable routing. Policy interactions could lead to “livelock” protocol oscillations. See “Persistent Route Oscillations in Inter-domain Routing” by K. Varadhan,

R. Govindan, and D. Estrin. ISI report, 1996 • Corollary: BGP is not guaranteed to recover

from network failures.

Underlying problem

Shortest Paths

Distributed means of computing a solution.

X?

RIP, OSPF, IS-IS

BGP

What Problem is BGP Solving?

Separate dynamic and static semantics

SPVP = Simple Path Vector Protocol = a distributed algorithm for solving SPP

BGP

SPVP

Booo Hooo, Many, many complications...

BGP Policies

Stable Paths Problem (SPP)

staticsemantics

dynamicsemantics

1

An instance of the Stable Paths Problem (SPP)

2 5 5 2 1 0

0

2 1 02 0

1 3 01 0

3 0

4 2 04 3 0

3

4

2

1

• A graph of nodes and edges, • Node 0, called the origin, • For each non-zero node, a set

or permitted paths to the origin. This set always contains the “null path”.

• A ranking of permitted paths at each node. Null path is always least preferred. (Not shown in diagram)

When modeling BGP : nodes represent BGP speaking routers, and 0 represents a node originating some address block

most preferred…least preferred

Yes, the translation gets messy!

5 5 2 1 0

1

A Solution to a Stable Paths Problem

2

0

2 1 02 0

1 3 01 0

3 0

4 2 04 3 0

3

4

2

1

• node u’s assigned path is either the null path or is a path uwP, where wP is assigned to node w and {u,w} is an edge in the graph,

• each node is assigned the highest ranked path among those consistent with the paths assigned to its neighbors.

A Solution need not represent a shortest path tree, or a spanning tree.

A solution is an assignment of permitted paths to each node such that

An SPP may have multiple solutions

First solution

1

0

2

1 2 01 0

1

0

2

1

0

2

2 1 02 0

1 2 01 0

2 1 02 0

1 2 01 0

2 1 02 0

Second solutionDISAGREE

Multiple solutions can result in “Route Triggering”

1

02

3

1 01 2 3 0

2 3 02 1 0

3 2 1 03 0

1

02

3

1

02

3

Remove primary link Restore primary link

1 01 2 3 0

2 3 02 1 0

3 2 1 03 0

primary link

backup link

BAD GADGET

2

0

31

2 1 02 0

1 3 01 0

3 2 03 0

4

3

Persistent Route Oscillations in Inter-Domain Routing. Kannan Varadhan, Ramesh Govindan, and Deborah Estrin. Computer Networks, Jan. 2000

SURPRISE : Beware of Backup Policies

2

0

31

2 1 02 0

1 3 01 0

3 4 2 03 0

4

4 04 2 04 3 0

Becomes a BAD GADGET if link (4, 0) goes down.

BGP is not robust : it is not guaranteed to recover from network failures.

PRECARIOUS

1

0

2

1 2 01 0

2 1 02 0

3

4

5 6

5 3 1 05 6 3 1 2 05 3 1 2 0

6 3 1 06 4 3 1 2 06 3 1 2 0

4 3 1 04 5 3 1 2 04 3 1 2 0

3 1 03 1 2 0

As with DISAGREE, this part has two distinct solutions

This part has a solution only when node 1 is assigned the direct path (1 0).

Distributed algorithms to solve SPP?

• OSPF-like :– Distribute topology, path ranks– Solve SPP locally– Exponential worst case– How can loops be avoided when multiple solutions

exist?

• RIP-like:– Pick the best path from the set of your neighbor’s paths,

tell your neighbors when you change your mind– Can diverge– Not guaranteed to find a solution, even when one exists– Even when converges, no bound on convergence time

This is BGP…

SPVP protocol

process spvp[u] { receive P from w { rib-in(uw) := u P if rib(u) != best(u) { rib(u) := best(u)

foreach v in peers(u) { send rib(u) to v } } } }

Pick the best path available at any given time…

SPVP wanders around assignment space

= assignment = solution

Solving an SPP

Just enumerate all path assignmentsAnd check stability of each….

Exponential complexity

But, in worst case you (probably) can’t do any better…

Use 3-SAT…Variables V = {X1, X2, …, Xn}

Clauses C1 = X17 or ~X23 or ~X3, C2 = ~X2 or X3 or ~X12 …. Cm = X6 or ~X7 or X18

Question Is there an variable assignment A : V {true, false} such that each clause C1, … ,Cm is true?

3-SAT is NP-complete

Modeling assignment to variable X

X

0

X

X = trueX = false

X

0X

X

0X

X X 0

X 0

X X 0

X 0

SPP Solvability is NP-complete

BAD GADGET

0

X5 X5X7 X7 X3 X3

CX7 or X5 or X3

C X7 0C X5 0C X3 0

A sufficient condition for sanity

Static (SPP)

solvable

Dynamic (SPVP)

unique solution

safe (can’t diverge)

predictable restoration

If an instance of SPP has an acyclic dispute digraph, then

all sub-problems uniquely solvable

robust with respect to link/node failures

Dispute Digraph

…(u v)P…(u v)Q...

…Q…P...

u v 0P

Q

Q (u v)P

Gives the dispute arc

Dispute Digraph (cont.)

…(u,v)P...

…P...

u v 0P

P (u,v)P

Gives the transmission arc

Dispute Digraph Example

21

0

43

1 3 01 0

2 1 02 0

4 2 0

4 3 0

3 4 2 0

3 0

3 4 2 0

2 1 0

2 0 1 0

3 0

4 3 0 1 3 0

4 2 0

BAD GADGET II

CYCLE

PART VII

Selected Bibliography

Addressing and ASN RFCs

• RFC 1380 IESG Deliberations on Routing and Addressing (1992) • RFC 1517Applicability Statement for the Implementation of Classless Inter-Domain Routing

(CIDR) (1993) • RFC 1518 An Architecture for IP Address Allocation with CIDR (1993) • RFC 1519 Classless Inter-Domain Routing (CIDR) (1993) • RFC 1467 Status of CIDR Deployment in the Intrenet (1983) • RFC 1520 Exchanging Routing Information Across Provider Boundaries in the CIDR

Environment (1993) • RFC 1817 CIDR and Classful routing (1995) • RFC 1918 Address Allocation for Private Internets (1996) • RFC 2008 Implications of Various Address Allocation Policies for Internet Routing (1996) • RFC 2050 Internet Registry IP Allocation Guidelines (1996) • RFC 2260 Scalable Support for Multi-homed Multi-provider Connectivity (1998) • RFC 2519 A Framework for Inter-Domain Route Aggregation (1999)• RFC 1930 Guidelines for creation, selection, and registration of an Autonomous System (AS) • RFC 2270 Using a Dedicated AS for Sites Homed to a Single Provider

Selected BGP RFCs

• IDR : http://www.ietf.org/html.charters/idr-charter.html

• RFC 1771 A Border Gateway Protocol 4 (BGP-4)

• Latest draft rewrite: draft-ietf-idr-bgp4-18.txt

• RFC 1772 Application of the Border Gateway Protocol in the Internet

• RFC 1773 Experience with the BGP-4 protocol

• RFC 1774 BGP-4 Protocol Analysis

• RFC 2796 BGP Route Reflection An alternative to full mesh IBGP

• RFC 3065 Autonomous System Confederations for BGP

• RFC 1997 BGP Communities Attribute

• RFC 1998 An Application of the BGP Community Attribute in Multi-home Routing

• RFC 2439 Route Flap Dampening

Internet Engineering Task Force (IETF)

http://www.ietf.org

Titles of Some Recent Internet Drafts

• Dynamic Capability for BGP-4• Application of Multiprotocol BGP-4 to IPv4 Multicast Routing • Graceful Restart mechanism for BGP• Cooperative Route Filtering Capability for BGP-4• Address Prefix Based Outbound Route Filter for BGP-4• Aspath Based Outbound Route Filter for BGP-4• Architectural Requirements for Inter-Domain Routing in the Internet• BGP support for four-octet AS number space• Autonomous System Number Substitution on Egress• BGP Extended Communities Attribute• Controlling the redistribution of BGP routes• BGP Persistent Route Oscillation Condition• Benchmarking Methodology for Basic BGP Convergence• Terminology for Benchmarking External Routing Convergence Measurements

BGP is a moving target …

75

Selected Bibliography on Routing

• Internet Routing Architectures. Bassam Halabi. Second edition Cisco Press, 2000

• BGP4: Inter-domain Routing in the Internet. John W. Stewart, III. Addison-Wesley, 1999

• Routing in the Internet. Christian Huitema. 2000

• ISP Survival Guide: Strategies for Running a Competitive ISP. Geoff Huston. Wiley, 1999.

• Interconnection, Peering and Settlements. Geoff Huston. The Internet Protocol Journal. March and June 1999.

BGP Stability and Convergence

• Route Flap Damping Exacerbates Internet Routing Convergence. Z.M.Mao, R.Govindan, G.Varghese,R.H.Kranz. SIGCOMM 2002.

• The Impact of Internet Policy and Topology on Delayed Routing Convergence. Craig Labovitz, Abha Ahuja, Roger Wattenhofer, Srinivasan Venkatachary. INFOCOM 2001

• An Experimental Study of BGP Convergence. Craig Labovitz, Abha Ahuja, Abhijit Abose, Farnam Jahanian. SIGCOMM 2000

• Origins of Internet Routing Instability. C. Labovitz, R. Malan, F. Jahanian. INFOCOM 1999

• Internet Routing Instability. Craig Labovitz, G. Robert Malan and Farnam Jahanian. SIGCOMM 1997

Analysis of Interdomain Routing

• Cooperative Association for Internet Data Analysis (CAIDA)– http://www.caida.org/– Tools and analyses promoting the engineering and maintenance of a

robust, scalable global Internet infrastructure

• Internet Performance Measurement and Analysis (IPMA)– http://www.merit.edu/ipma/– Studies the performance of networks and networking protocols in local

and wide-area networks

• National Laboratory for Applied Network Research (NLANR)– http://www.nlanr.net/– Analysis, tools, visualization.

• IRTF Routing Research Group (IRTF-RR)– http://puck.nether.net/irtf-rr/

• Geoff Huston: http://bgp.potaroo.net

Internet Route Registries

• Internet Route Registry– http://www.irr.net/

• Routing Policy Specification Language (RPSL)– RFC 2622 Routing Policy Specification Language

(RPSL) – RFC 2650 Using RPSL in Practice

• Internet Route Registry Daemon (IRRd)– http://www.irrd.net/

• RAToolSet – http://www.isi.edu/ra/RAToolSet/

Some BGP Theory• Persistent Route Oscillations in Inter-Domain Routing. Kannan Varadhan, Ramesh Govindan, and

Deborah Estrin. Computer Networks, Jan. 2000. (Also USC Tech Report, Feb. 1996)– Shows that BGP is not guaranteed to converge

• An Architecture for Stable, Analyzable Internet Routing. Ramesh Govindan, Cengiz Alaettinoglu, George Eddy, David Kessens, Satish Kumar, and WeeSan Lee. IEEE Network Magazine, Jan-Feb 1999.

– Use RPSL to specify policies. Store them in registries. Use registry for conguration generation and analysis.

• An Analysis of BGP Convergence Properties. Timothy G. Griffin, Gordon Wilfong. SIGCOMM 1999– Model BGP, shows static analysis of divergence in policies is NP complete

• Policy Disputes in Path Vector Protocols. Timothy G. Griffin, F. Bruce Shepherd, Gordon Wilfong. ICNP 1999

– Define Stable Paths Problem and develop sufficient condition for “sanity”• A Safe Path Vector Protocol. Timothy G. Griffin, Gordon Wilfong. INFOCOM 2001

– Dynamic solution for SPVP based on histories• Stable Internet Routing without Global Coordination. Lixin Gao, Jennifer Rexford. SIGMETRICS

2000– Show that if certain guidelines are followed, then all is well.

• Inherently safe backup routing with BGP. Lixin Gao, Timothy G. Griffin, Jennifer Rexford. INFOCOM 2001

– Use SPP to study complex backup policies– On the Correctness of IBGP Configurations. Griffin and Wilfong.SIGCOMM 2002. – An Analysis of the MED oscillation Problem. Griffin and Wilfong. ICNP 2002.

Pointers

• Links on Interdomain routing and BGP:

• http://www.research.att.com/~griffin/interdomain.html

• SIGCOMM 2001 Tutorial on BGP:

• http://www.research.att.com/~griffin/sigcomm2001_bgp_tutorial/abstract.html

• Papers on BGP theory:

• http://www.research.att.com/~griffin/bgpresearch.html

griffin@research.att.com