draft-ietf-bmwg-conterm-04.txt   draft-ietf-bmwg-conterm-05.txt 
Benchmarking Working Group H. Berkowitz Benchmarking Working Group H. Berkowitz
Internet-Draft Gett Communications Internet-Draft Gett Communications
Expires: September 1, 2003 E. Davies (ed.) Expires: December 29, 2003 E. Davies (ed.)
Nortel Networks Nortel Networks
S. Hares S. Hares
Nexthop Technologies Nexthop Technologies
P. Krishnaswamy P. Krishnaswamy
SAIC SAIC
M. Lepp M. Lepp
Consultant Consultant
A. Retano June 30, 2003
Cisco Systems, Inc.
March 3, 2003
Terminology for Benchmarking BGP Device Convergence in the Control Terminology for Benchmarking BGP Device Convergence in the Control
Plane Plane
draft-ietf-bmwg-conterm-04.txt draft-ietf-bmwg-conterm-05.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 41 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 1, 2003. This Internet-Draft will expire on December 29, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This draft establishes terminology to standardize the description of This draft establishes terminology to standardize the description of
benchmarking methodology for measuring eBGP convergence in the benchmarking methodology for measuring eBGP convergence in the
control plane of a single BGP device. Future documents will address control plane of a single BGP device. Future documents will address
iBGP convergence, the initiation of forwarding based on converged iBGP convergence, the initiation of forwarding based on converged
control plane information and multiple interacting BGP devices. This control plane information and multiple interacting BGP devices. This
terminology is applicable to both IPv4 and IPv6. Illustrative terminology is applicable to both IPv4 and IPv6. Illustrative
examples of each version are included where relevant. examples of each version are included where relevant.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Overview and Roadmap . . . . . . . . . . . . . . . . . . . . 4 1.1 Overview and Roadmap . . . . . . . . . . . . . . . . . . . . 4
1.2 Definition Format . . . . . . . . . . . . . . . . . . . . . 5 1.2 Definition Format . . . . . . . . . . . . . . . . . . . . . 5
2. Components and characteristics of Routing information . . . 6 2. Components and Characteristics of Routing Information . . . 6
2.1 (Network) Prefix . . . . . . . . . . . . . . . . . . . . . . 6 2.1 (Network) Prefix . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Network Prefix Length . . . . . . . . . . . . . . . . . . . 6 2.2 Network Prefix Length . . . . . . . . . . . . . . . . . . . 6
2.3 Route . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 Route . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 BGP Route . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 BGP Route . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Network Level Reachability Information (NLRI) . . . . . . . 8 2.5 Network Level Reachability Information (NLRI) . . . . . . . 8
2.6 BGP UPDATE message . . . . . . . . . . . . . . . . . . . . . 8 2.6 BGP UPDATE Message . . . . . . . . . . . . . . . . . . . . . 8
3. Routing Data Structures and Route Categories . . . . . . . . 9 3. Routing Data Structures and Route Categories . . . . . . . . 9
3.1 Routing Information Base (RIB) . . . . . . . . . . . . . . . 9 3.1 Routing Information Base (RIB) . . . . . . . . . . . . . . . 9
3.1.1 Adj-RIB-In and Adj-RIB-Out . . . . . . . . . . . . . . . . . 9 3.1.1 Adj-RIB-In and Adj-RIB-Out . . . . . . . . . . . . . . . . . 9
3.1.2 Loc-RIB . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2 Loc-RIB . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Routing Policy . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 Routing Policy . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Routing Policy Information Base . . . . . . . . . . . . . . 10 3.3 Routing Policy Information Base . . . . . . . . . . . . . . 10
3.4 Forwarding Information Base (FIB) . . . . . . . . . . . . . 11 3.4 Forwarding Information Base (FIB) . . . . . . . . . . . . . 11
3.5 BGP Instance . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5 BGP Instance . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6 BGP Device . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.6 BGP Device . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.7 BGP Session . . . . . . . . . . . . . . . . . . . . . . . . 13 3.7 BGP Session . . . . . . . . . . . . . . . . . . . . . . . . 13
3.8 Active BGP Session . . . . . . . . . . . . . . . . . . . . . 13 3.8 Active BGP Session . . . . . . . . . . . . . . . . . . . . . 13
3.9 BGP Peer . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.9 BGP Peer . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.10 BGP Neighbor . . . . . . . . . . . . . . . . . . . . . . . . 14 3.10 BGP Neighbor . . . . . . . . . . . . . . . . . . . . . . . . 14
3.11 MinRouteAdvertisementInterval (MRAI) . . . . . . . . . . . . 14 3.11 MinRouteAdvertisementInterval (MRAI) . . . . . . . . . . . . 14
3.12 MinASOriginationInterval (MAOI) . . . . . . . . . . . . . . 15 3.12 MinASOriginationInterval (MAOI) . . . . . . . . . . . . . . 15
3.13 Active Route . . . . . . . . . . . . . . . . . . . . . . . . 15 3.13 Active Route . . . . . . . . . . . . . . . . . . . . . . . . 15
3.14 Unique Route . . . . . . . . . . . . . . . . . . . . . . . . 16 3.14 Unique Route . . . . . . . . . . . . . . . . . . . . . . . . 16
3.15 Non-Unique Route . . . . . . . . . . . . . . . . . . . . . . 16 3.15 Non-Unique Route . . . . . . . . . . . . . . . . . . . . . . 16
3.16 Route Instance . . . . . . . . . . . . . . . . . . . . . . . 16 3.16 Route Instance . . . . . . . . . . . . . . . . . . . . . . . 16
4. Constituent elements of a router or network of routers. . . 18 4. Constituent Elements of a Router or Network of Routers . . . 18
4.1 Default Route, Default Free Table, and Full Table . . . . . 18 4.1 Default Route, Default Free Table, and Full Table . . . . . 18
4.1.1 Default Route . . . . . . . . . . . . . . . . . . . . . . . 18 4.1.1 Default Route . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.2 Default Free Routing Table . . . . . . . . . . . . . . . . . 18 4.1.2 Default Free Routing Table . . . . . . . . . . . . . . . . . 18
4.1.3 Full Default Free Table . . . . . . . . . . . . . . . . . . 19 4.1.3 Full Default Free Table . . . . . . . . . . . . . . . . . . 19
4.1.4 Default-Free Zone . . . . . . . . . . . . . . . . . . . . . 19 4.1.4 Default-Free Zone . . . . . . . . . . . . . . . . . . . . . 20
4.1.5 Full Provider-Internal Table . . . . . . . . . . . . . . . . 20 4.1.5 Full Provider-Internal Table . . . . . . . . . . . . . . . . 20
4.2 Classes of BGP-Speaking Routers . . . . . . . . . . . . . . 20 4.2 Classes of BGP-Speaking Routers . . . . . . . . . . . . . . 20
4.2.1 Provider Edge Router . . . . . . . . . . . . . . . . . . . . 20 4.2.1 Provider Edge Router . . . . . . . . . . . . . . . . . . . . 20
4.2.2 Subscriber Edge Router . . . . . . . . . . . . . . . . . . . 21 4.2.2 Subscriber Edge Router . . . . . . . . . . . . . . . . . . . 21
4.2.3 Inter-provider Border Router . . . . . . . . . . . . . . . . 21 4.2.3 Inter-provider Border Router . . . . . . . . . . . . . . . . 21
4.2.4 Core Router . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.4 Core Router . . . . . . . . . . . . . . . . . . . . . . . . 22
5. Characterization of sets of update messages . . . . . . . . 23 5. Characterization of Sets of Update Messages . . . . . . . . 23
5.1 Route Packing . . . . . . . . . . . . . . . . . . . . . . . 23 5.1 Route Packing . . . . . . . . . . . . . . . . . . . . . . . 23
5.2 Route Mixture . . . . . . . . . . . . . . . . . . . . . . . 23 5.2 Route Mixture . . . . . . . . . . . . . . . . . . . . . . . 23
5.3 Update Train . . . . . . . . . . . . . . . . . . . . . . . . 24 5.3 Update Train . . . . . . . . . . . . . . . . . . . . . . . . 24
5.4 Randomness in Update Trains . . . . . . . . . . . . . . . . 25 5.4 Randomness in Update Trains . . . . . . . . . . . . . . . . 25
5.5 Route Flap . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.5 Route Flap . . . . . . . . . . . . . . . . . . . . . . . . . 26
6. Route Changes and Convergence . . . . . . . . . . . . . . . 27 6. Route Changes and Convergence . . . . . . . . . . . . . . . 27
6.1 Route Change Events . . . . . . . . . . . . . . . . . . . . 27 6.1 Route Change Events . . . . . . . . . . . . . . . . . . . . 27
6.2 Device Convergence in the Control Plane . . . . . . . . . . 28 6.2 Device Convergence in the Control Plane . . . . . . . . . . 28
7. BGP Operation Events . . . . . . . . . . . . . . . . . . . . 30 7. BGP Operation Events . . . . . . . . . . . . . . . . . . . . 30
7.1 Hard reset . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.1 Hard Reset . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.2 Soft reset . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.2 Soft Reset . . . . . . . . . . . . . . . . . . . . . . . . . 30
8. Factors that impact the performance of the convergence 8. Factors that Impact the Performance of the Convergence
process . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Process . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1 General factors affecting device convergence . . . . . . . . 32 8.1 General Factors Affecting Device Convergence . . . . . . . . 32
8.1.1 Number of peers . . . . . . . . . . . . . . . . . . . . . . 32 8.1.1 Number of Peers . . . . . . . . . . . . . . . . . . . . . . 32
8.1.2 Number of routes per peer . . . . . . . . . . . . . . . . . 32 8.1.2 Number of Routes per Peer . . . . . . . . . . . . . . . . . 32
8.1.3 Policy processing/reconfiguration . . . . . . . . . . . . . 32 8.1.3 Policy Processing/Reconfiguration . . . . . . . . . . . . . 32
8.1.4 Interactions with other protocols . . . . . . . . . . . . . 32 8.1.4 Interactions with Other Protocols . . . . . . . . . . . . . 32
8.1.5 Flap Damping . . . . . . . . . . . . . . . . . . . . . . . . 33 8.1.5 Flap Damping . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1.6 Churn . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 8.1.6 Churn . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.2 Implementation-specific and other factors affecting BGP 8.2 Implementation-specific and other Factors Affecting BGP
convergence . . . . . . . . . . . . . . . . . . . . . . . . 33 Convergence . . . . . . . . . . . . . . . . . . . . . . . . 34
8.2.1 Forwarded traffic . . . . . . . . . . . . . . . . . . . . . 34 8.2.1 Forwarded Traffic . . . . . . . . . . . . . . . . . . . . . 34
8.2.2 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 8.2.2 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.2.3 TCP parameters underlying BGP transport . . . . . . . . . . 34 8.2.3 TCP Parameters Underlying BGP Transport . . . . . . . . . . 34
8.2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 34 8.2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 34
9. Security Considerations . . . . . . . . . . . . . . . . . . 35 9. Security Considerations . . . . . . . . . . . . . . . . . . 35
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 36 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 36
Normative References . . . . . . . . . . . . . . . . . . . . 37 Normative References . . . . . . . . . . . . . . . . . . . . 37
Informative References . . . . . . . . . . . . . . . . . . . 38 Informative References . . . . . . . . . . . . . . . . . . . 38
For Internet Draft consistency purposes only . . . . . . . . 39 For Internet Draft consistency purposes only . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . . 41
1. Introduction 1. Introduction
skipping to change at page 4, line 43 skipping to change at page 4, line 43
consisting of the arrival, processing, and propagation of routing consisting of the arrival, processing, and propagation of routing
information. information.
We note that for testing purposes all optional parameters should be We note that for testing purposes all optional parameters should be
turned off. All variable parameters should be in their default turned off. All variable parameters should be in their default
setting unless specified by the test. setting unless specified by the test.
Subsequent drafts will explore the more intricate aspects of Subsequent drafts will explore the more intricate aspects of
convergence measurement, such as the impacts of the presence of convergence measurement, such as the impacts of the presence of
Multiprotocol Extensions for BGP-4, policy processing, simultaneous Multiprotocol Extensions for BGP-4, policy processing, simultaneous
traffic on the control and data paths within the DUT, and other traffic on the control and data paths within the Cevice Under Test
realistic performance modifiers. Convergence of Interior Gateway (DUT), and other realistic performance modifiers. Convergence of
Protocols will also be considered in separate drafts. Interior Gateway Protocols will also be considered in separate
drafts.
1.1 Overview and Roadmap 1.1 Overview and Roadmap
Characterizations of the BGP convergence performance of a device must Characterizations of the BGP convergence performance of a device must
take into account all distinct stages and aspects of BGP take into account all distinct stages and aspects of BGP
functionality. This requires that the relevant terms and metrics be functionality. This requires that the relevant terms and metrics be
as specifically defined as possible. Such definition is the goal of as specifically defined as possible. Such definition is the goal of
this document. this document.
The necessary definitions are classified into separate categories: The necessary definitions are classified into separate categories:
skipping to change at page 6, line 5 skipping to change at page 6, line 5
Measurement units: Measurement units:
The units used to report measurements of this term, if applicable. The units used to report measurements of this term, if applicable.
Issues: Issues:
List of issues or conditions that could affect this term. List of issues or conditions that could affect this term.
See Also: See Also:
List of related terms that are relevant to the definition or List of related terms that are relevant to the definition or
discussion of this term. discussion of this term.
2. Components and characteristics of Routing information 2. Components and Characteristics of Routing Information
2.1 (Network) Prefix 2.1 (Network) Prefix
Definition: Definition:
"A network prefix is a contiguous set of bits at the more "A network prefix is a contiguous set of bits at the more
significant end of the address that collectively designates the significant end of the address that collectively designates the
set of systems within a network; host numbers select among those set of systems within a network; host numbers select among those
systems." (This definition is taken directly from section 2.2.5.2, systems." (This definition is taken directly from section 2.2.5.2,
"Classless Inter Domain Routing (CIDR)", in [3].) "Classless Inter Domain Routing (CIDR)", in [3].)
skipping to change at page 6, line 38 skipping to change at page 6, line 38
Definition: Definition:
The network prefix length is the number of bits out of the total The network prefix length is the number of bits out of the total
available in the address field, used to define the network prefix. available in the address field, used to define the network prefix.
Discussion: Discussion:
A common alternative to using a bit-wise mask to communicate this A common alternative to using a bit-wise mask to communicate this
component is the use of "slash (/) notation." Slash notation binds component is the use of "slash (/) notation." Slash notation binds
the notion of network prefix length in bits to an IP address. the notion of network prefix length in bits to an IP address.
E.g., 141.184.128.0/17 indicates the network component of this E.g., 141.184.128.0/17 indicates the network component of this
IPv4 address is 17 bits wide. Similar notation is used for IPv6 IPv4 address is 17 bits wide. Similar notation is used for IPv6
network prefixes e.g. :FF02:20::/24 network prefixes e.g. 2001:db8:719f::/48
When referring to groups of addresses, the network prefix length When referring to groups of addresses, the network prefix length
is often used as a means of describing groups of addresses as an is often used as a means of describing groups of addresses as an
equivalence class. For example, 'one hundred /16 addresses' equivalence class. For example, 'one hundred /16 addresses'
refers to 100 addresses whose network prefix length is 16 bits. refers to 100 addresses whose network prefix length is 16 bits.
Measurement units: bits Measurement units: bits
Issues: Issues:
See Also: network prefix See Also: network prefix
2.3 Route 2.3 Route
Definition: Definition:
In general, a 'route' is the n-tuple In general, a 'route' is the n-tuple
<prefix, nexthop, other routing or non-routing protocol <prefix, nexthop [, other routing or non-routing protocol
attributes]> attributes]>
A route is not end-to-end, but is defined with respect to a A route is not end-to-end, but is defined with respect to a
specific next hop that will move traffic closer to the destination specific next hop that should take packets on the next step
defined by the prefix. In this usage, a route is the basic unit of towards their destination as defined by the prefix. In this usage,
information about a target destination distilled from routing a route is the basic unit of information about a target
protocols. destination distilled from routing protocols.
Discussion: Discussion:
This term refers to the concept of a route common to all routing This term refers to the concept of a route common to all routing
protocols. With reference to the definition above, typical protocols. With reference to the definition above, typical
non-routing-protocol attributes would be associated with diffserv non-routing-protocol attributes would be associated with diffserv
or traffic engineering. or traffic engineering.
Measurement Units: N.A. Measurement Units: N.A.
Issues: None. Issues: None.
skipping to change at page 8, line 8 skipping to change at page 8, line 8
Measurement Units: N.A. Measurement Units: N.A.
Issues: Issues:
See Also: Route, prefix, Adj-RIB-in, NLRI. See Also: Route, prefix, Adj-RIB-in, NLRI.
2.5 Network Level Reachability Information (NLRI) 2.5 Network Level Reachability Information (NLRI)
Definition: Definition:
The NRLI consists of one or more network prefixes with the same The NLRI consists of one or more network prefixes with the same
set of path attributes. set of path attributes.
Discussion: Discussion:
Each prefix in the NLRI is combined with the (common) path Each prefix in the NLRI is combined with the (common) path
attributes to form a BGP route. The NLRI encapsulates a set of attributes to form a BGP route. The NLRI encapsulates a set of
destinations to which packets can be routed (from this point in destinations to which packets can be routed (from this point in
the network) along a common route described by the path the network) along a common route described by the path
attributes. attributes.
Measurement Units: N.A. Measurement Units: N.A.
Issues: Issues:
See Also: Route Packing, Network Prefix, BGP Route, NLRI See Also: Route Packing, Network Prefix, BGP Route, NLRI
2.6 BGP UPDATE message 2.6 BGP UPDATE Message
Definition: Definition:
An UPDATE message contains an advertisement of a single NLRI An UPDATE message contains an advertisement of a single NLRI
field, possibly containing multiple prefixes, and multiple field, possibly containing multiple prefixes, and multiple
withdrawals of unfeasible routes. See RFC 1771 ([1]) for details. withdrawals of unfeasible routes. See RFC 1771 ([1]) for details.
Discussion: Discussion:
From RFC 1771: "A variable length sequence of path attributes is From RFC 1771: "A variable length sequence of path attributes is
present in every UPDATE. Each path attribute is a triple present in every UPDATE. Each path attribute is a triple
<attribute type, attribute length, attribute value> of variable <attribute type, attribute length, attribute value> of variable
skipping to change at page 10, line 10 skipping to change at page 10, line 10
Definition: Definition:
The Loc-RIB contains the set of best routes selected from the The Loc-RIB contains the set of best routes selected from the
various Adj-RIBs, after applying local policies and the BGP route various Adj-RIBs, after applying local policies and the BGP route
selection algorithm. selection algorithm.
Discussion: Discussion:
The separation implied between the various RIBs is logical. It The separation implied between the various RIBs is logical. It
does not necessarily follow that these RIBs are distinct and does not necessarily follow that these RIBs are distinct and
separate entities in any given implementation. separate entities in any given implementation.
Types of routes can include internal BGP, external BGP, interface, Types of routes that need to be considered include internal BGP,
static and IGP routes. external BGP, interface, static and IGP routes.
Issues: Issues:
Measurement Units: Number of routes Measurement Units: Number of routes
See Also: See Also:
Route, BGP Route, Route Instance, Adj-RIB-in, Adj-RIB-out,FIB Route, BGP Route, Route Instance, Adj-RIB-in, Adj-RIB-out,FIB
3.2 Routing Policy 3.2 Routing Policy
skipping to change at page 13, line 41 skipping to change at page 13, line 41
Measurement units: N/A Measurement units: N/A
Issues: Issues:
See Also: See Also:
3.9 BGP Peer 3.9 BGP Peer
Definition: Definition:
A BGP peer is another BGP instance to which the Device Under Test A BGP peer is another BGP instance to which the DUT is in the
(DUT) is in the Established state. (See RFC 1771 [1]). Established state. (See RFC 1771 [1]).
Discussion: Discussion:
In the test scenarios in the methodology discussion that will In the test scenarios in the methodology discussion that will
follow this draft, peers send BGP advertisements to the DUT and follow this draft, peers send BGP advertisements to the DUT and
receive DUT-originated advertisements. We recommend that the receive DUT-originated advertisements. We recommend that the
peering relation be established before tests are begun. It might peering relation be established before tests are begun. It might
also be interesting to measure the time required to reach the also be interesting to measure the time required to reach the
established state. established state.
This is a protocol-specific definition, not to be confused with This is a protocol-specific definition, not to be confused with
skipping to change at page 17, line 6 skipping to change at page 17, line 6
Definition: Definition:
A route instance is one of several possible occurrences of a route A route instance is one of several possible occurrences of a route
for a particular prefix. for a particular prefix.
Discussion: Discussion:
When a router has multiple peers from which it accepts routes, When a router has multiple peers from which it accepts routes,
routes to the same prefix may be received from several peers. This routes to the same prefix may be received from several peers. This
is then an example of multiple route instances. is then an example of multiple route instances.
Each route instance is associated with a specific peer. The BGP Each route instance is associated with a specific peer. The BGP
selection algorithm may reject a specific route instance due to algorithm that arbitrates between the available candidate route
local policy. instances may reject a specific route instance due to local
policy.
Measurement Units: Number of route instances Measurement Units: Number of route instances
Issues: Issues:
The number of route instances in the Adj-RIB-in bases will vary The number of route instances in the Adj-RIB-in bases will vary
based on the function to be performed by a router. An based on the function to be performed by a router. An
inter-provider border router, located in the default free zone inter-provider border router, located in the default-free zone
(not defined) will likely receive more route instances than a (see Section 4.1.4) will likely receive more route instances than
provider edge router, located closer to the end-users of the a provider edge router, located closer to the end-users of the
network. network.
See Also: See Also:
4. Constituent elements of a router or network of routers. 4. Constituent Elements of a Router or Network of Routers
Many terms included in this list of definitions were originally Many terms included in this list of definitions were originally
described in previous standards or papers. They are included here described in previous standards or papers. They are included here
because of their pertinence to this discussion. Where relevant, because of their pertinence to this discussion. Where relevant,
reference is made to these sources. An effort has been made to keep reference is made to these sources. An effort has been made to keep
this list complete with regard to the necessary concepts without over this list complete with regard to the necessary concepts without over
definition. definition.
4.1 Default Route, Default Free Table, and Full Table 4.1 Default Route, Default Free Table, and Full Table
An individual router's routing table may not necessarily contain a An individual router's routing table may not necessarily contain a
default route. Not having a default route, however, is not default route. Not having a default route, however, is not
synonymous with having a full default-free table(DFT). synonymous with having a full default-free table(DFT). Also, a
router which has a full set of routes as in a DFT but also has a
'discard' rule for a default route would not be considered as default
free.
It should be noted that the references to number of routes in this It should be noted that the references to number of routes in this
section document are to routes installed in the loc-RIB and are section document are to routes installed in the loc-RIB and are
therefore unique routes, not route instances, and that the total therefore unique routes, not route instances, and that the total
number of route instances may be 4 to 10 times the number of routes. number of route instances may be 4 to 10 times the number of routes.
4.1.1 Default Route 4.1.1 Default Route
Definition: Definition:
A Default Route can match any destination address. If a router A Default Route can match any destination address. If a router
does not have a more specific route for a particular packet's does not have a more specific route for a particular packet's
destination address, it forwards this packet to the next hop in destination address, it forwards this packet to the next hop in
the default route entry, provided its Forwarding Table (Forwarding the default route entry, provided its Forwarding Table (Forwarding
Information Base (FIB) contains one. The notation for a default Information Base (FIB) contains one). The notation for a default
route for IPv4 is 0.0.0.0/0 and for IPv6 it is 0:0:0:0:0:0:0:0 or route for IPv4 is 0.0.0.0/0 and for IPv6 it is 0:0:0:0:0:0:0:0 or
::/0. ::/0.
Discussion: Discussion:
Measurement units: N.A. Measurement units: N.A.
Issues: Issues:
See Also: default free routing table, route, route instance See Also: default free routing table, route, route instance
skipping to change at page 20, line 20 skipping to change at page 20, line 26
See Also: Default Route See Also: Default Route
4.1.5 Full Provider-Internal Table 4.1.5 Full Provider-Internal Table
Definition: Definition:
A full provider-internal table is a superset of the full routing A full provider-internal table is a superset of the full routing
table that contains infrastructure and non- aggregated routes. table that contains infrastructure and non- aggregated routes.
Discussion: Discussion:
Experience has shown that this table can contain 1.3 to 1.5 times Experience has shown that this table might contain 1.3 to 1.5
the number of routes in the externally visible full table. Tables times the number of routes in the externally visible full table.
of this size, therefore, are a real-world requirement for key Tables of this size, therefore, are a real-world requirement for
internal provider routers. key internal provider routers.
Measurement Units: number of routes Measurement Units: number of routes
Issues: Issues:
See Also: Routes, Route Instances, Default Route See Also: Routes, Route Instances, Default Route
4.2 Classes of BGP-Speaking Routers 4.2 Classes of BGP-Speaking Routers
A given router may perform more than one of the following functions, A given router may perform more than one of the following functions,
based on its logical location in the network. based on its logical location in the network.
4.2.1 Provider Edge Router 4.2.1 Provider Edge Router
Definition: Definition:
A provider edge router is a router at the edge of a provider's A provider edge router is a router at the edge of a provider's
network that speaks eBGP to a BGP speaker in another AS. network that speaks eBGP to a BGP speaker in another AS.
Discussion: Discussion:
The traffic that transits this router may be destined to, or The traffic that transits this router may be destined to, or
originate from non-contiguous autonomous systems. originate from non-adjacent autonomous systems. In particular the
MED values used in the Provider Edge Router would not be visible
in the non-adjacent autonomous systems.
Such a router will always speak eBGP and may speak iBGP. Such a router will always speak eBGP and may speak iBGP.
Measurement units: Measurement units:
Issues: Issues:
See Also: See Also:
4.2.2 Subscriber Edge Router 4.2.2 Subscriber Edge Router
skipping to change at page 21, line 25 skipping to change at page 21, line 31
Discussion: Discussion:
The router belongs to an end user organization that may be multi- The router belongs to an end user organization that may be multi-
homed, and which carries traffic only to and from that end user homed, and which carries traffic only to and from that end user
AS. AS.
Such a router will always speak eBGP and may speak iBGP. Such a router will always speak eBGP and may speak iBGP.
Measurement units: Measurement units:
Issues: Issues:
This definition of an enterprise border router (which is what most
Subscriber Edge Routers are) is practical rather than rigorous. It
is meant to draw attention to the reality that many enterprises
may need a BGP speaker that advertises their own routes and
accepts either default alone or partial routes. In such cases,
they may be interested in benchmarks that use a partial routing
table, to see if a smaller control plane processor will meet their
needs.
See Also: See Also:
4.2.3 Inter-provider Border Router 4.2.3 Inter-provider Border Router
Definition: Definition:
An inter-provider border router is a BGP speaking router which An inter-provider border router is a BGP speaking router which
maintains BGP sessions with otherBGP speaking routers in other maintains BGP sessions with otherBGP speaking routers in other
providers' ASs. providers' ASs.
skipping to change at page 22, line 19 skipping to change at page 22, line 32
net, speaking iBGP to that provider's edge routers, other intra- net, speaking iBGP to that provider's edge routers, other intra-
provider core routers, or the provider's inter-provider border provider core routers, or the provider's inter-provider border
routers. routers.
Discussion: Discussion:
Such a router will always speak iBGP and may speak eBGP. Such a router will always speak iBGP and may speak eBGP.
Measurement units: Measurement units:
Issues: Issues:
Then by this definition they aren't core routers. Then by this definition the DUT's which are eBGP routers aren't
core routers.
See Also: See Also:
5. Characterization of sets of update messages 5. Characterization of Sets of Update Messages
This section contains a sequence of definitions that build up to the This section contains a sequence of definitions that build up to the
definition of an Update Train. The Packet train concept was definition of an Update Train. The Packet train concept was
originally introduced by Jain and Routhier [11]. It is here adapted originally introduced by Jain and Routhier [11]. It is here adapted
to refer to a train of packets of interest in BGP performance to refer to a train of packets of interest in BGP performance
testing. testing.
This is a formalization of the sort of test stimulus that is expected This is a formalization of the sort of test stimulus that is expected
as input to a DUT running BGP. This data could be a as input to a DUT running BGP. This data could be a
well-characterized, ordered and timed set of hand-crafted BGP UPDATE well-characterized, ordered and timed set of hand-crafted BGP UPDATE
skipping to change at page 29, line 33 skipping to change at page 29, line 33
definition is intended (so far as is possible) to exclude any definition is intended (so far as is possible) to exclude any
additional time such as is needed to download and install the additional time such as is needed to download and install the
forwarding information base in the data plane. This definition forwarding information base in the data plane. This definition
should be usable for different families of protocols. should be usable for different families of protocols.
It is of key importance to benchmark the performance of each phase It is of key importance to benchmark the performance of each phase
of convergence separately before proceeding to a composite of convergence separately before proceeding to a composite
characterization of routing convergence, where characterization of routing convergence, where
implementation-specific dependencies are allowed to interact. 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 The time resolution needed to measure the device convergence
depends to some extent on the types of the interfaces on the depends to some extent on the types of the interfaces on the
router. For modern routers with gigabit or faster interfaces, an router. For modern routers with gigabit or faster interfaces, an
individual UPDATE may be processed and re-advertised in very much individual UPDATE may be processed and re-advertised in very much
less than a millisecond so that time measurements must be made to less than a millisecond so that time measurements must be made to
a resolution of hundreds to tens of microseconds or better. a resolution of hundreds to tens of microseconds or better.
Measurement Units: Measurement Units:
Time period. Time period.
skipping to change at page 30, line 16 skipping to change at page 30, line 16
The BGP process(es) in a device might restart because operator The BGP process(es) in a device might restart because operator
intervention or a power failure caused a complete shut-down. In this intervention or a power failure caused a complete shut-down. In this
case a hard reset is needed. A peering session could be lost, for 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 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 session. A device can reestablish its peers and re-advertise all
relevant routes in a hard reset. However, if a peer is lost, but 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 the BGP process has not failed, BGP has mechanisms for a "soft
reset." reset."
7.1 Hard reset 7.1 Hard Reset
Definition: Definition:
An event which triggers a complete re-initialization of the An event which triggers a complete re-initialization of the
routing tables on one or more BGP sessions, resulting in exchange routing tables on one or more BGP sessions, resulting in exchange
of a full routing table on one or more links to the router. of a full routing table on one or more links to the router.
Discussion: Discussion:
Measurement Units: N/A Measurement Units: N/A
Issues: Issues:
See Also: See Also:
7.2 Soft reset 7.2 Soft Reset
Definition: Definition:
A soft reset is performed on a per-neighbor basis; it does not A soft reset is performed on a per-neighbor basis; it does not
clear the BGP session while re-establishing the peering relation clear the BGP session while re-establishing the peering relation
and does not stop the flow of traffic. and does not stop the flow of traffic.
Discussion: Discussion:
There are two methods of performing a soft reset: Graceful restart There are two methods of performing a soft reset: Graceful restart
[13] where the BGP device that has lost a peer but continues to [13] where the BGP device that has lost a peer but continues to
forward traffic for a period of time before tearing down the forward traffic for a period of time before tearing down the
peer's routes. The alternative method is soft refresh [12], where peer's routes. The alternative method is soft refresh [12], where
a BGP device can request a peer's Adj-RIB-Out. a BGP device can request a peer's Adj-RIB-Out.
Measurement Units: N/A Measurement Units: N/A
Issues: Issues:
See Also: See Also:
8. Factors that impact the performance of the convergence process 8. Factors that Impact the Performance of the Convergence Process
While this is not a complete list, all of the items discussed below While this is not a complete list, all of the items discussed below
have a significant affect on BGP convergence. Not all of them can be have a significant affect on BGP convergence. Not all of them can be
addressed in the baseline measurements described in this document. addressed in the baseline measurements described in this document.
8.1 General factors affecting device convergence 8.1 General Factors Affecting Device Convergence
These factors are conditions of testing external to the router Device These factors are conditions of testing external to the router Device
Under Test (DUT). Under Test (DUT).
8.1.1 Number of peers 8.1.1 Number of Peers
As the number of peers increases, the BGP route selection algorithm As the number of peers increases, the BGP route selection algorithm
is increasingly exercised. In addition, the phasing and frequency of is increasingly exercised. In addition, the phasing and frequency of
updates from the various peers will have an increasingly marked updates from the various peers will have an increasingly marked
effect on the convergence process on a router as the number of peers effect on the convergence process on a router as the number of peers
grows. Increasing the number of peers also increases the processing grows, depending on the quantity of updates that is generated by each
workload for TCP and BGP keepalives. 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 8.1.2 Number of Routes per Peer
The number of routes per BGP peer is an obvious stressor to the The number of routes per BGP peer is an obvious stressor to the
convergence process. The number, and relative proportion, of multiple convergence process. The number, and relative proportion, of multiple
route instances and distinct routes being added or withdrawn by each route instances and distinct routes being added or withdrawn by each
peer will affect the convergence process, as will the mix of peer will affect the convergence process, as will the mix of
overlapping route instances, and IGP routes. overlapping route instances, and IGP routes.
8.1.3 Policy processing/reconfiguration 8.1.3 Policy Processing/Reconfiguration
The number of routes and attributes being filtered, and set, as a The number of routes and attributes being filtered, and set, as a
fraction of the target route table size is another parameter that fraction of the target route table size is another parameter that
will affect BGP convergence. will affect BGP convergence.
Extreme examples are Extreme examples are
o Minimal Policy: receive all, send all, o Minimal Policy: receive all, send all,
o Extensive policy: up to 100% of the total routes have applicable o Extensive policy: up to 100% of the total routes have applicable
policy. policy.
8.1.4 Interactions with other protocols 8.1.4 Interactions with Other Protocols
There are interactions in the form of precedence, synchronization, There are interactions in the form of precedence, synchronization,
duplication and the addition of timers, and route selection criteria. duplication and the addition of timers, and route selection criteria.
Ultimately, understanding BGP4 convergence must include understanding Ultimately, understanding BGP4 convergence must include understanding
of the interactions with both the IGPs and the protocols associated of the interactions with both the IGPs and the protocols associated
with the physical media, such as Ethernet, SONET, DWDM. with the physical media, such as Ethernet, SONET, DWDM.
8.1.5 Flap Damping 8.1.5 Flap Damping
A router can use flap damping to respond to route flapping. Use of A router can use flap damping to respond to route flapping. Use of
skipping to change at page 33, line 50 skipping to change at page 34, line 5
initialization condition. initialization condition.
Flapping routes are a pathological contributor to churn, as is MED Flapping routes are a pathological contributor to churn, as is MED
oscillation [16]. The goal of flap damping is to reduce the oscillation [16]. The goal of flap damping is to reduce the
contribution of flapping to churn. contribution of flapping to churn.
The effect of churn on overall convergence depends on the processing The effect of churn on overall convergence depends on the processing
power available to the control plane, and whether the same power available to the control plane, and whether the same
processor(s) are used for forwarding and for control. processor(s) are used for forwarding and for control.
8.2 Implementation-specific and other factors affecting BGP convergence 8.2 Implementation-specific and other Factors Affecting BGP Convergence
These factors are conditions of testing internal to the Device Under These factors are conditions of testing internal to the Device Under
Test (DUT), although they may affect its interactions with test Test (DUT), although they may affect its interactions with test
devices. devices.
8.2.1 Forwarded traffic 8.2.1 Forwarded Traffic
The presence of actual traffic in the device may stress the control 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 path in some fashion if both the offered load due to data and the
control traffic (FIB updates and downloads as a consequence of control traffic (FIB updates and downloads as a consequence of flaps)
flaps)are excessive. The addition of data traffic presents a more are excessive. The addition of data traffic presents a more accurate
accurate reflection of realistic operating scenarios than if only reflection of realistic operating scenarios than if only control
control traffic is present. traffic is present.
8.2.2 Timers 8.2.2 Timers
Settings of delay and hold-down timers at the link level as well as 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 for BGP4, can introduce or ameliorate delays. As part of a test
report, all relevant timers should be reported if they use non- report, all relevant timers should be reported if they use non-
default value. default value.
8.2.3 TCP parameters underlying BGP transport 8.2.3 TCP Parameters Underlying BGP Transport
Since all BGP traffic and interactions occur over TCP, all relevant Since all BGP traffic and interactions occur over TCP, all relevant
parameters characterizing the TCP sessions should be provided: e.g. parameters characterizing the TCP sessions should be provided: e.g.
Slow start, max window size, maximum segment size, or timers. Slow start, max window size, maximum segment size, or timers.
8.2.4 Authentication 8.2.4 Authentication
Authentication in BGP is currently done using the TCP MD5 Signature Authentication in BGP is currently done using the TCP MD5 Signature
Option [8]. The processing of the MD5 hash, particularly in devices Option [8]. The processing of the MD5 hash, particularly in devices
with a large number of BGP peers and a large amount of update traffic with a large number of BGP peers and a large amount of update traffic
skipping to change at page 37, line 5 skipping to change at page 36, line 12
affecting feature, but does not consider the overall security of the affecting feature, but does not consider the overall security of the
routing system. routing system.
10. Acknowledgments 10. Acknowledgments
Thanks to Francis Ovenden for review and Abha Ahuja for Thanks to Francis Ovenden for review and Abha Ahuja for
encouragement. Much appreciation to Jeff Haas, Matt Richardson, and encouragement. Much appreciation to Jeff Haas, Matt Richardson, and
Shane Wright at Nexthop for comments and input. Debby Stopp and Nick Shane Wright at Nexthop for comments and input. Debby Stopp and Nick
Ambrose contributed the concept of route packing. 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.
Normative References Normative References
[1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", [1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995. RFC 1771, March 1995.
[2] Villamizar, C., Chandra, R. and R. Govindan , "BGP Route Flap [2] Villamizar, C., Chandra, R. and R. Govindan , "BGP Route Flap
Damping", RFC 2439, November 1998. Damping", RFC 2439, November 1998.
[3] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, [3] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995. June 1995.
[4] Ahuja, A., Jahanian, F., Bose, A. and C. Labovitz, "An [4] Ahuja, A., Jahanian, F., Bose, A. and C. Labovitz, "An
Experimental Study of Delayed Internet Routing Convergence", Experimental Study of Delayed Internet Routing Convergence",
RIPE-37 Presentation to Routing WG, June 2000, <http:// RIPE-37 Presentation to Routing WG, November 2000, <http://
www.ripe.net/ripe/meetings/archive/ripe-37/presentations/ www.ripe.net/ripe/meetings/archive/ripe-37/presentations/
RIPE-37-convergence/>. RIPE-37-convergence/>.
[5] Labovitz, C., Malan, G. and F. Jahanian, "Origins of Internet [5] Labovitz, C., Malan, G. and F. Jahanian, "Origins of Internet
Routing Instability", Infocom 99, August 1999. Routing Instability", Infocom 99, August 1999.
[6] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., [6] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing
Policy Specification Language (RPSL)", RFC 2622, June 1999. Policy Specification Language (RPSL)", RFC 2622, June 1999.
skipping to change at page 40, line 8 skipping to change at page 41, line 4
SAIC SAIC
331 Newman Springs Road 331 Newman Springs Road
Red Bank, New Jersey 07701 Red Bank, New Jersey 07701
USA USA
EMail: kri1@earthlink.net EMail: kri1@earthlink.net
Marianne Lepp Marianne Lepp
Consultant Consultant
EMail: mlepp@lepp.com EMail: mlepp@lepp.com
Alvaro Retana
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
USA
EMail: aretana@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/