Craig et al have done, and are continuing to do, valuable work on
Internet-wide convergence. Their measurements, however, reflect a
wide range of factors affecting convergence, including media speeds,
propagation times, policies, etc.
The presentation does not formalize the definition of convergence,
but, in any case, there appear to be several useful meanings of "BGP
convergence time.," Lack of standard terminology leads both to
difficulty in comparing research results, and generating FUD for
Internet operators and consumers.
Existing benchmarking documents, such as RFC 2544, focus on
forwarding performance rather than convergence.
I'm not sure if this belongs here or in BMWG, but let me throw out
some working definitions, with the intention of starting discussion.
1. Types of Convergence
Two significantly different types of convergence time tend to be
lumped together in product specifications. The first is the time
needed for a BGP speaker to build a full table after initialization,
or for a particular peering session to rebuild its table after a hard
reset. The second is the time needed for a router to respond to a new
announcement or withdrawal.
1.1 Reference Configuration
A basic configuration is optimized for testing.
TR1==========+---------+==========TR3
| | |
D1 | |
| | DUT |
TR2==========| |
| |
...
TRn==========+---------+
D1 is a destination reachable by both TR1 and TR2. It is assumed that
neither TR1 or TR2 is the originating AS for the announcement of D1.
Other test configurations might emulate the environments of:
-- two default-free providers
-- multilateral peering at an exchange point
-- upstream provider to a large (TBD) number of transit customers
1.2 Test Conditions
More complex peering arrangements can involve up to n Test Routers.
Performance as a function of number of peers is important but TBD.
Interface speeds will be specified as part of the test report. At
least 100 Mbps is recommended, so media delays are not a signficant
component of the convergence time.
The size of the RIB to be used is TBD, but should be at least 100K
routes for a router intended for default-free use. Smaller RIBs may
be used with routers explicitly intended for edge use with defaults,
and the assumptions cited.
In the absence of other route selection criteria, TR1 shall have an
IP address that makes it most preferred.
2. Measurement
Measurements can be defined either as internal or external. Internal
measurements examine the RIB of the DUT. While they are more accurate
in principle, they require measurement hooks in the implementation.
External measurements start with a stimulus from one or more
"upstream" routers and end with a specific event causing an
advertisement to be sent to a "downstream" peer. In the reference
configuration above, external measurements are defined with respect
to TR3 as the downstream router.
3. eBGP tests
All routers in this configuration have a policy of ADVERTISE
ALL/ACCEPT ALL. Tests with prefix filtering, community-based
preferences, etc., as well as performance under flap are TBD.
3.1 eBGP Initial Convergence
While this is relatively simple to measure, and often is the basis of
product specifications, it is operationally far less significant than
reconvergence after changes. A "carrier-grade" router should not
initialize often, and the soft reset option reduces the need to
rebuild views. The initialization time, therefore, can be amortized
over a long period of time and may disappear into the noise when
compared to reconvergence.
3.1.1 Initial Convergence Time
The test begins with OPEN requests sent from TR1 and TR2 to the DUT.
Each Test Router sends a standard routing table of ___ routes.
3.2 eBGP Reconvergence
3.2.1 Time to Add Newly Advertised Route
The DUT has been initialized, with no path to D. TR1 announces D to the DUT.
3.2.2 Time to Change to Alternate Path after Withdrawal
The DUT has been initialized and has paths to D via both TR1 and TR2.
TR1's path is preferred, but TR1 withdraws it. Reconvergence occurs
when the TR2 advertised paths becomes active.
3.2.3 Time to Reconverge after Sequential Withdraw and New Announcement
The DUT has been initialized and has a path to D1 via TR1, not TR2.
Simultaneously, TR1 withdraws the route and TR2 announces it.
4. iBGP Full Mesh tests
TBD
5. iBGP Route Reflector tests
TBD
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT