Network Working Group R. White
Internet-Draft Cisco Systems
Expires: September 13, 2008 J. Burns
Wachovia
March 12, 2008
Common Practices in Routing Protocols Deployment
draft-white-rppract-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 13, 2008.
Abstract
This document discusses common practices used in deploying routing
protocols in both public and private networks. The focus is not to
describe how routing protocols should be deployed, but rather how
they are generally deployed, to provide those working on
specifications which impact the operation of routing protocols with
guidance in what will likely be deployed, or what will likely not be
deployed. The focus in thie document will be ionterdomain routing,
but it will cover aspects of intradomain routing, as well.
White & Burns Expires September 13, 2008 [Page 1]
Internet-Draft RP Common Practices March 2008
1. Background
When considering new extensions to existing routing protocols, it's
useful to consider them in the context of existing usage of these
protocols. Various questions come to mind, such as:
o Common Underlying Principles of Network Designs
o Common Practices in Route Origination
o Common Practices in Routing Database Management
o Common Practices in Aggregation
o Common Practices in Peering
o Common Practices in Security
o ....
Each of these topics will be covered in a separate section below.
2. Common Underlying Principles of Network Designs
There are a number of underlying principles most network designers
take into account when designing networks which don't fit neatly into
any single category below; these are covered in this section. Most
of these principles apply across multiple layers, and with many
different protocols, so while examples are given, these principles
can be found in many parts of any given network design, in ways that
may not be immediately obvious or apparent.
2.1. Network Growth
Networks always grow, through organic growth and through mergers and
aquisitions. To counter this, network design is often focused on the
removal of information from the routing database. There are three
types of information which are commonly removed from the routing
database:
o Fine grained reachability information is often replaced with more
gross levels of reachability information.
o State changes are often hidden at various points within the
network.
o Topology information is often reduced from a fine grain view of
the network to a single point of reachability.
One mechanism used to remove these types of information from the
routing database is the aggregation of routing data. Common
techniques used to aggregate routing data are covered in greater
detail in a later section. Removing information from the routing
database through aggregation virtually always causes suboptimal
routing. The corollary to this is that for finer grained traffic
White & Burns Expires September 13, 2008 [Page 2]
Internet-Draft RP Common Practices March 2008
control, more state is always required, hence traffic engineering
must always be balanced with stability in network design.
Another mechanism commonly used to remove information from the
routing database is virtualization, or splitting the network into two
pieces vertically, throughout the entire physical topology. One
instance of this is using BGP to carry external routes while carrying
an IGP to carry internal routes. This splits the database into two
pieces, based on the characteristics of the information, and carries
them separately. While the traffic being routed is carried along the
same topologies, the control plane data is split, or virtualized.
2.2. Deterministic Behaviour
Network designs often favor deterministic behaviour in the face of
failures or changes over non-deterministic behaviour. This is
generally supported by the observation that the Mean Time To Repair
is virtually always a larger component of network downtime than the
Mean Time Between Failures. Deterministic behaviour is a tremendous
aid in troubleshooting, which can decrease the Mean Time To Repair
dramatically. Some examples of designing for deterministic behaviour
include:
o Link metrics are normally manually engineered to select a primary
and alternate path through the network for any given source/
destination pair, rather than allowing the routing protocol to
naturally process the paths, and build paths which might fail over
in non-deterministic ways.
o Trees for routing multicast routing may be manually configured
throughout a network, to control the paths and backup paths
available to certain classes of traffic
2.3. Convergence Verses Network Stability
Newer classes of traffic place a great deal of load on network
convergence. At one time, a convergence time of 3 to 9 minutes was
considered acceptable, as witnessed by the default timers and
operation of early distance-vector protocols. Networks now must
contend with very high speed links, across which loops with durations
in the 100s of milliseconds can lead to a total failure of sections
of the network. Networks must also contend with applications which
cannot accept any loss of connectivity above the 100s of
milliseconds, and some applications which cannot tolerate any packet
loss.
The primary problem with these sorts of requirements is that
extermely high network convergence speeds allow no time for dampening
rapid changes in the network, and, in fact, can amplify rapid network
White & Burns Expires September 13, 2008 [Page 3]
Internet-Draft RP Common Practices March 2008
changes, reducing network stability, sometimes to the point where the
network fails to converge. Network design thus must be built around
converging quickly while maintaining stability, a sometimes difficult
balance to achieve. Some of the techniques designers use to balance
between stability and convergence speed include:
o Pushing detection as close to the hardware as possible. For
instance, point-to-point links are used where possible, so the
physical media state is tied directly to the logical media state.
o When logical state doesn't track physical state directly, using
layer 2 mechanisms where possible to detect circuit outages.
o Using exponential backoff and other dampening mechanisms to
prevent a positive feedback loop from forming, adversely impacting
network performance.
3. Common Practices in Route Origination
Interior and exterior gateway protocols have a number of ways in
which they classify routing information, the primary of which is the
way in which destinations have been injected into the protocol.
3.1. Interior Gateway Protocols
For interior gateway protocols, routing information is normally
classified as originating either from within the protocol, or from a
source which is external to the protocol. Destinations which are
learned of through a direct connection, such as a connection to a
subnet on a router running the protocol, are called internal routes.
Destinations which are learned of through some other means, outside
the protocol, are called external routes.
Virtually all routing information is injected into interior gateway
protocols as internal routing information, unless there is a specific
reason for injecting external information into the IGP routing
domain. Some specific reasons might include:
When multiple routing protocols are being used in the same
network. Generally, this occurs when two networks are merged, or
when a part of the network runs a different routing protocol for
policy or design reasons.
When interaction is occuring with a network not under the local
administrator's control. Generally, injecting external live
routing information between interior gateway protocols between
routing domains is not encouraged, but there are instances when
this occurs.
White & Burns Expires September 13, 2008 [Page 4]
Internet-Draft RP Common Practices March 2008
To inject manually configured reachability information into the
protocol. This generally occurs along the edges of a network, to
provide reachability to destinations not within the network
itself.
To provide reachability across some form of layer 3 virtual
private network, when no mechanism is deployed or supported to
provide the transport of native routing information across the
VPN.
Generally, injection of external routing information is avoided where
possible in network designs, unless there is a specific policy or
design related reason to do so.
3.2. Exterior Gateway Protocols
For exterior gateway protocols, the distinction between internal and
external routing information is blurred, as all information is
considered to be external. There is an indicator of where a specific
piece of routing information originated, but this information is used
very low on the decision process, and so it's generally not
considered a factor in route choice.
However, there is another aspect of route origination which is a
common concern in exterior gateway protocols, such as [BGP]--how
routing information is locally originated on a given router. In all
implementations of [BGP], routing information can either be
originated from the local routing table, or it can be originated from
a local manually configured route. Generally, to improve network
stability, routes are injected into BGP by manually configuring a
local static route, and injecting the manually configured route into
the protocol, rather than by pulling information from the dynamic
routing table.
4. Common Practices in Routing Database Management
When managing policies and filters in the routing database, explicit
and obvious mechanisms are generally preferred over implicit, or less
obvious, mechanisms. Some examples of this include:
o When redistribution between routing protocols, route tags are
preferred over lists of redistributed routes to prevent routing
loops from forming.
o When filtering at an AS boundary in [BGP], filtering based on the
AS Path length is generally preferred over filtering on
communities, or other attributes, because the AS Path is obvious
and well known, while a lot of network engineers will not examine
other attributes.
White & Burns Expires September 13, 2008 [Page 5]
Internet-Draft RP Common Practices March 2008
5. Common Practices in Aggregation
Aggregation of reachability information in a network occurs both in
the IGP and the the EGP, and there are different common practices for
each one. The two section below discuss these practices. In a third
section, the common practice of allowing longer prefixes matches
through an aggregation point is discussed.
5.1. Aggregation Practices in IGPs
Normally, aggregation in IGP is performed through manual
configuration, and the aggregate route information is pulled from the
local RIB. Quite often, the metric of the resulting aggregate route
is forced to remain constant (which prevents state changes in one
part of the network from impacting other parts of the network)
through the use of a virtual interface, or a manually configured
metrics attached to the aggregation configuration.
5.2. Aggregation Practices in EGPs
While aggregation commands are available in most implementations of
[BGP], and there are extensive rules covering how to aggregation the
various attributes of a set of aggregated routes, aggregation is not
used in most BGP deployments. Instead, it is much more common for a
manually configured route to originated into BGP to advertise an
aggregate. Filters are normally used in conjunction with these
manually originated routes to prevent components of the aggregate
from being leaked to peering routers.
5.3. Allowing Components Through Aggregation
It is common to allow components to be advertised along with
aggregated routing information to provide optimal routing to specific
destinations. To provide an example:
+----[B]---10.1.2.0/24
| |
[A] +----10.1.3.0/24
| |
+----[C]---10.1.4.0/24
In this network, the network designer might want to reduce the amount
of routing data and state flowing to A. In order to do this, manual
summaries can be configured at B and C, so only a shorter prefix
covering all the reachable destinations is advertised. However, as
noted earlier, the consequence of configuring this manual aggregation
of routing information would be the introduction of suboptimal
routing in the network, from A, towards 10.1.2.0/24 and 10.1.4.0/24.
White & Burns Expires September 13, 2008 [Page 6]
Internet-Draft RP Common Practices March 2008
To counter this, the network engineer might opt to leak these two
specific routes through the aggregate.
What is seen from the outside as a "multihoming" problem is, then,
actually a traffic engineering problem. Most often providing two
alternate paths in any network will result in the desire to optimally
route traffic through those paths, whether they are equal cost or
not. In most cases, leaking more specific reachability information
is the quickest and most obvious way to reach the right balance of
routing information verses optimal routing.
6. Common Practices In Peering
Many network design problems need to be taken into account when
setting up peering, both for IGPs and for [BGP]. Common practices in
this area include:
eBGP peers are normally set up for fast down detection where
possible, which is generally only possible with sessions over
point-to-point links.
eBGP sessions are generally manually configured not to accept a
TCP keepalive timer less than 10 or 15 seconds, to prevent the
peering router from negotiating very low TCP keepalive timers,
which consumes processor.
[OSPF] designated routers and [IS-IS] Designated Intermediate
Systems are normally chosen through manual configuration.
Deterministic behaviour is the goal in all cases where one router
within a set is chosen for a role or a specific set of processing.
7. Common Practices in Security
Security practices generally center around preventing state changes
and false routing information from entering the network, and
preventing access to infrastructure devices, including routers,
within the network. Some commonly used techniques in this area
include:
o Filtering reachability information at network edges so
infrastructure devices are not reachable outside the network.
o Configuring packet filters at network edges to directly prevent
infrastructure devices from being reached from outside the
network.
o Filtering reachability information at network edges to prevent the
injection of private routes, bogus routes, or routes used for
internal infrastructure.
White & Burns Expires September 13, 2008 [Page 7]
Internet-Draft RP Common Practices March 2008
o Route count limiters at the network edge where live routing data
is accepted from an outside network, to prevent overflowing local
routing tables.
Cryptographic secuirity mechanisms, such as MD5, are not generally
configured for various reasons, including:
o Processing requirements cryptographic mechanisms are generally
high, which can produce generally undesirable side effects.
o Key management for cryptographic mechanisms is generally difficult
to imeplement and manage.
8. Acknowledgements
....
9. Informative References
[BGP-MD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
Authors' Addresses
Russ White
Cisco Systems
Phone:
Fax:
Email: riw@cisco.com
URI:
John Burns
Wachovia
Phone:
Fax:
Email: john.burns1@wachovia.com
URI:
White & Burns Expires September 13, 2008 [Page 8]
Internet-Draft RP Common Practices March 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
White & Burns Expires September 13, 2008 [Page 9]