SSFNet BGP and Challenges in BGP Simulation

1
SSFNet BGP andChallenges in BGP Simulation
BJ Premore, David Nicol, Michael Liljenstam
Dartmouth College
Jim Cowie, Andy Ogielski Renesys Corporation
November 14, 2002
2
Overview

• making a reliable BGP testbed
• how much detail?
• impact of protocol variations
• implementation issues encountered
• protocol variations
• unclear specification
• memory usage
• organizing large sets of experiments
• SOS

3
What does it take to make a reliable BGP testbed?

• the details matter
• physical and routed connectivity differ
• policy (limits topology)
• static and dynamic connectivity differ
• delayed convergence Labovitz et al.
• flapping dampening
• processing time
• especially for S-BGP
• increases instability
• should match operational reality

4
How much impact doprotocol variations have?

• it varies, but can be significant
• repeated updates Griffin
• withdrawal rate limiting
• loop detection method
• comparison with Labovitz et al., SIGCOMM 2000
• radical but compliant "stateless" BGP
• simulation is ideal for comparing
• implement each variation as an option

5
Comparing Loop Detection Methods
clique size 15 after withdrawal
6
Implementation Issues Encountered

• vendor implementation variations
• support them all
• unclear or unspecified behavior
• left to implementor
• example loop detection method
• tricky wording
• again, support all reasonable variations

7
A Quote from the RFC
regarding advertisement rate limiting
Any technique which ensures that the
interval between two UPDATE messages sent from a
single BGP speaker that advertise feasible routes
to some common set of destinations received
from BGP speakers in neighboring autonomous
systems will be at least MinRouteAdvertisementInte
rval, and will also ensure a constant upper bound
on the interval is acceptable.
8
Implementation Issues Encountered

• memory usage grows quickly
• proportional to V2E (routers 2sessions)
• bottom line number of peering sessions
• clique vs. realistic topo
• long path length is also a factor
• multiple prefixes per AS hard to reuse

9
Alleviating the Memory Problem

• at the cost of some functionality
• hash table instead of radix tree
• aggregation no longer possible
• 40 memory reduction
• flat AS paths overlapping AS paths
• segment types no longer used
• 20 memory reduction
• others basic attributes, simple policy,
  attribute reuse
• lt 5 reduction
• mileage will vary

10
Organizing Large Sets of Experiments

• general issue large parameter spaces to explore
• SOS (www.cs.dartmouth.edu/research/sos/)
• Create families and groups of experiments
• Specify DML template, parameter values, and
  extractors
• Automatically generates DML, runs sets of
  experiments, extracts desired measurements
• Stores results in database
• millions of simulations run using it

11
Conclusions

• in applications where dynamic routing is a factor
  (routers go up/down, etc.), the routing
  simulation should be comparable to that of real
  operational networks
• protocol variations can make a difference, so
  exploring each of them is important
• SOS can help with this
• memory usage is a challenge