Because we are trying to benchmark the routing protocol
performance, which is only a part of the device overall, this
definition is intended (as far as is possible) to exclude any
additional time needed to download and install the
forwarding information base in the data plane. This definition is
usable for different families of protocols.
It is of key importance to benchmark the performance of each phase
of convergence separately before proceeding to a composite
characterization of routing convergence, where
implementation-specific dependencies are allowed to interact.
Care also needs to be taken to ensure that the convergence time is
not influenced by policy processing on downstream peers.
The time resolution needed to measure the device convergence
depends to some extent on the types of the interfaces on the
router. For modern routers with gigabit or faster interfaces, an
individual UPDATE may be processed and re-advertised in very much
less than a millisecond so that time measurements must be made to
a resolution of hundreds to tens of microseconds or better.
Measurement units:
Time period.
Issues:
See also:
7. BGP Operation Events
The BGP process(es) in a device might restart because operator
intervention or a power failure caused a complete shutdown. In this
case, a hard reset is needed. A peering session could be lost, for
example, because of action on the part of the peer or a dropped TCP
session. A device can reestablish its peers and re-advertise all
relevant routes in a hard reset. However, if a peer is lost, but
the BGP process has not failed, BGP has mechanisms for a "soft
reset."
7.1. Hard Reset
Definition:
An event that triggers a complete re-initialization of the
routing tables on one or more BGP sessions, resulting in exchange
of a full routing table on one or more links to the router.
Discussion:
Measurement units: N.A.
Issues:
See also:
7.2. Soft Reset
Definition:
A soft reset is performed on a per-neighbor basis; it does not
clear the BGP session while re-establishing the peering relation
and does not stop the flow of traffic.
Discussion:
There are two methods of performing a soft reset: (1) graceful
restart [GRMBGP], wherein the BGP device that has lost a
peer continues to forward traffic for a period of time before
tearing down the peer’s routes and (2) soft
refresh [RFC2918], wherein a BGP device can request a peer’s
Adj-RIB-Out.
Measurement units: N.A.
Issues:
See also:
8. Factors That Impact the Performance of the Convergence Process
Although this is not a complete list, all the items discussed below
have a significant effect on BGP convergence. Not all of them can be
addressed in the baseline measurements described in this document.
8.1. General Factors Affecting Device Convergence
These factors are conditions of testing external to the router Device
Under Test (DUT).
8.1.1. Number of Peers
As the number of peers increases, the BGP route selection algorithm
is increasingly exercised. In addition, the phasing and frequency of
updates from the various peers will have an increasingly marked
effect on the convergence process on a router as the number of peers
grows, depending on the quantity of updates generated by each
additional peer. Increasing the number of peers also increases the
processing workload for TCP and BGP keepalives.
8.1.2. Number of Routes per Peer
The number of routes per BGP peer is an obvious stressor to the
convergence process. The number and relative proportion of
multiple route instances and distinct routes being added or withdrawn
by each peer will affect the convergence process, as will the mix of
overlapping route instances and IGP routes.
8.1.3. Policy Processing/Reconfiguration
The number of routes and attributes being filtered and set as a
fraction of the target route table size is another parameter that
will affect BGP convergence.
The following are extreme examples:
o Minimal policy: receive all, send all.
o Extensive policy: up to 100% of the total routes have applicable
policy.
8.1.4. Interactions with Other Protocols
There are interactions in the form of precedence, synchronization,
duplication, and the addition of timers and route selection criteria.
Ultimately, understanding BGP4 convergence must include an
understanding of the interactions with both the IGPs and the
protocols associated with the physical media, such as Ethernet,
SONET, and DWDM.
8.1.5. Flap Damping
A router can use flap damping to respond to route flapping. Use of
flap damping is not mandatory, so the decision to enable the feature,
and to change parameters associated with it, can be considered a
matter of routing policy.
The timers are defined by RFC 2439 [RFC2439] and discussed in RIPE-
229 [RIPE229]. If this feature is in effect, it requires that the
device keep additional state to carry out the damping, which can have
a direct impact on the control plane due to increased processing. In
addition, flap damping may delay the arrival of real changes in a
route and affect convergence times.
8.1.6. Churn
In theory, a BGP device could receive a set of updates that
completely define the Internet and could remain in a steady state,
only sending appropriate keepalives. In practice, the Internet will
always be changing.
Churn refers to control-plane processor activity caused by
announcements received and sent by the router. It does not include
keepalives and TCP processing.
Churn is caused by both normal and pathological events. For example,
if an interface of the local router goes down and the associated
prefix is withdrawn, that withdrawal is a normal activity, although
it contributes to churn. If the local device receives a withdrawal
of a route it already advertises, or an announcement of a route it
did not previously know, and it re-advertises this information, these
are normal constituents of churn. Routine updates can range from
single announcements or withdrawals, to announcements of an entire
default-free table. The latter is completely reasonable as an
initialization condition.
Flapping routes are a pathological contributor to churn, as is MED
oscillation [RFC3345]. The goal of flap damping is to reduce the
contribution of flapping to churn.
The effect of churn on overall convergence depends on the processing
power available to the control plane, and on whether the same
processor(s) are used for forwarding and control.
8.2. Implementation-Specific and Other Factors Affecting BGP
Convergence
These factors are conditions of testing internal to the Device Under
Test (DUT), although they may affect its interactions with test
devices.
8.2.1. Forwarded Traffic
The presence of actual traffic in the device may stress the control
path in some fashion if both the offered load (due to data) and the
control traffic (FIB updates and downloads as a consequence of flaps)
are excessive. The addition of data traffic presents a more accurate
reflection of realistic operating scenarios than would be presented
if only control traffic were present.
8.2.2. Timers
Settings of delay and hold-down timers at the link level, as well as
for BGP4, can introduce or ameliorate delays. As part of a test
report, all relevant timers MUST be reported if they use non-default
values.
8.2.3. TCP Parameters Underlying BGP Transport
Because all BGP traffic and interactions occur over TCP, all relevant
parameters characterizing the TCP sessions MUST be provided; e.g.,
slow start, max window size, maximum segment size, or timers.
8.2.4. Authentication
Authentication in BGP is currently done using the TCP MD5 Signature
Option [RFC2385]. The processing of the MD5 hash, particularly in
devices with a large number of BGP peers and a large amount of update
traffic, can have an impact on the control plane of the device.
9. Security Considerations
The document explicitly considers authentication as a performance-
affecting feature, but does not consider the overall security of the
routing system.
10. Acknowledgements
Thanks to Francis Ovenden for review and Abha Ahuja for
encouragement. Much appreciation to Jeff Haas, Matt Richardson, and
Shane Wright at Nexthop for comments and input. Debby Stopp and Nick
Ambrose contributed the concept of route packing.
Alvaro Retana was a key member of the team that developed this
document, and made significant technical contributions regarding
route mixes. The team thanks him and regards him as a co-author in
spirit.
11. References
11.1. Normative References
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route
Flap Damping", RFC 2439, November 1998.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RIPE37] Ahuja, A., Jahanian, F., Bose, A., and C. Labovitz, "An
Experimental Study of Delayed Internet Routing
Convergence", RIPE-37 Presentation to Routing WG,
November 2000,
<http://www.ripe.net/ripe/meetings/archive/
ripe-37/presentations/RIPE-37-convergence/>
.
[INSTBLTY] Labovitz, C., Malan, G., and F. Jahanian, "Origins of
Internet Routing Instability", Infocom 99, August 1999.
[RFC2622] Alaettinoglu, C., Bates, T., Gerich, E., Karrenberg, D.,
Meyer, D., Terpstra, M., and C. Villamizar, "Routing
Policy Specification Language (RPSL)", RFC 2280, January
1998.
[RIPE229] Panigl, C., Schmitz, J., Smith, P., and C. Vistoli,
"RIPE Routing-WG Recommendation for coordinated route-
flap damping parameters, version 2", RIPE 229, October
2001.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC 2385, August 1998.
[GLSSRY] Juniper Networks, "Junos(tm) Internet Software
Configuration Guide Routing and Routing Protocols,
Release 4.2", Junos 4.2 and other releases, September
2000,
<http://www.juniper.net/techpubs/software/junos/junos42/
swcmdref42/html/glossary.html>
.
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
March 1999.
[PKTTRAIN] Jain, R. and S. Routhier, "Packet trains -- measurement
and a new model for computer network traffic", IEEE
Journal on Selected Areas in Communication 4(6),
September 1986.
11.2. Informative References
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC
2918, September 2000.
[GRMBGP] Sangli, S., Rekhter, Y., Fernando, R., Scudder, J., and
E. Chen, "Graceful Restart Mechanism for BGP", Work in
Progress, June 2004.
[BGP-4] Chen, E. and Y. Rekhter, "Cooperative Route Filtering
Capability for BGP-4", Work in Progress, March 2004.
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for
Separation of IP Control and Forwarding", RFC 3654,
November 2003.
[RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana,
"Border Gateway Protocol (BGP) Persistent Route
Oscillation Condition", RFC 3345, August 2002.
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June
2000.
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545,
March 1999.
Authors’ Addresses
Howard Berkowitz
Gett Communications & CCI Training
5012 S. 25th St
Arlington, VA 22206
USA
Phone: +1 703 998-5819
Fax: +1 703 998-5058
EMail: hcb@gettcomm.com
Elwyn B. Davies
Folly Consulting
The Folly
Soham
Cambs, CB7 5AW
UK
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Susan Hares
Nexthop Technologies
825 Victors Way
Ann Arbor, MI 48108
USA
Phone: +1 734 222-1610
EMail: skh@nexthop.com
Padma Krishnaswamy
SAIC
331 Newman Springs Road
Red Bank, New Jersey 07701
USA
EMail: padma.krishnaswamy@saic.com
Marianne Lepp
Consultant
EMail: mlepp@lepp.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.