INTERNET DRAFT A Framework for Loop-free Convergence Jun 2005
Network Working Group S. Bryant
Internet Draft M. Shand
Expiration Date: Dec 2005 Cisco Systems
Jun 2005
Applicability of Loop-free Convergence
<draft-bryant-shand-lf-applicability-00.txt>
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This draft describes the applicability of loop free convergence
technologies to a number of network applications.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119
[RFC2119].
Bryant, Shand Expires Dec 2005 [Page 1]
INTERNET DRAFT A Framework for Loop-free Convergence Jun 2005
Table of Contents
1. Introduction........................................................3
2. Applicability.......................................................4
2.1. Component Failure...............................................4
2.2. Component Repair................................................4
2.3. Management withdrawal of a component............................5
2.4. Management Insertion of a Component.............................5
2.5. Management Change of a Link Cost................................5
2.6. External Cost Change............................................5
2.7. MPLS Applicability..............................................6
2.8. Routing Vector and Path Vector Convergence......................6
3. IANA considerations.................................................6
4. Security Considerations.............................................6
5. Intellectual Property Statement.....................................6
6. Full copyright statement............................................7
7. Normative References................................................7
8. Informative References..............................................7
9. Authors' Addresses..................................................8
Bryant, Shand Expires Dec 2005 [Page 2]
INTERNET DRAFT A Framework for Loop-free Convergence Jun 2005
1. Introduction
When there is a change to the network topology (due to the failure
or restoration of a link or router, or as a result of management
action) the routers need to converge on a common view of the new
topology, and the paths to be used for forwarding traffic to each
destination. During this process, referred to as a routing
transition, packet delivery between certain source/destination
pairs may be disrupted. This occurs due to the time it takes for
the topology change to be propagated around the network together
with the time it takes each individual router to determine and then
update the forwarding information base (FIB) for the affected
destinations. During this transition, packets are lost due to the
continuing attempts to use of the failed component, and due to
forwarding loops. Forwarding loops arise due to the inconsistent
FIBs that occur as a result of the difference in time taken by
routers to execute the transition process. This is a problem that
occurs in both IP networks and MPLS networks that use LDP [RFC3036]
as the label switched path (LSP) signaling protocol.
The service failures caused by routing transitions are largely
hidden by higher-level protocols that retransmit the lost data.
However new Internet services are emerging which are more sensitive
to the packet disruption that occurs during a transition. To make
the transition transparent to their users, these services require a
short routing transition. Ideally, routing transitions would be
completed in zero time with no packet loss.
Regardless of how optimally the mechanisms involved have been
designed and implemented, it is inevitable that a routing
transition will take some minimum interval that is greater than
zero. This has led to the development of a TE fast-reroute
mechanism for MPLS [MPLS-TE]. Alternative mechanisms that might be
deployed in an MPLS network and mechanisms that may be used in an
IP network are work in progress in the IETF [IPFRR]. Any repair
mechanism may however be disrupted by the formation of micro-loops
during the period between the time when the failure is announced,
and the time when all FIBs have been updated to reflect the new
topology.
This disruptive effect of micro-loops led the IP fast re-route
designers to develop mechanisms to control the re-convergence of
networks in order to prevent disruption of the repair and
collateral damage to other traffic in the network [LFFWK],[ZININ].
The purpose of this note is to draw the attention of the IETF
community to the more general nature of the micro-looping problem,
and the wider applicability of loop-free convergence technology.
Bryant, Shand Expires Dec 2005 [Page 3]
INTERNET DRAFT A Framework for Loop-free Convergence Jun 2005
2. Applicability
Loop free convergence strategies are applicable to any problem in
which inconsistency in the FIB causes the formation of micro-loops.
For example the convergence of a network following:
1) Component failure.
2) Component repair.
3) Management withdrawal of a component.
4) Management insertion or a component.
5) Management change of link cost (either positive or negative).
6) External cost change, for example change of external gateway as
a result of a BGP change.
7) An SRLG failure.
In each case, a component may be a link or a router.
2.1. Component Failure
When fast-reroute is used to provide the temporary repair of a
failed component, the use of a loop-free convergence mechanism
enables the re-convergence of the network without additional packet
loss caused by starvation or micro-looping as a result of
inconsistent FIBs.
The need for loop-free convergence was first appreciated during the
design of IP fast reroute. However the mechanism is also applicable
to the case where an MPLS-TE tunnel is used to provide a link or
node repair within an MPLS network where LDP is used to distribute
labels.
Except in special circumstances, controlled convergence in the
presence of component failure should only be used when a temporary
repair is available. This is because controlled convergence is
always slower than uncontrolled (traditional) convergence, and
would result in an extended period of traffic lost as a result of
the failure if there were no other means of delivering the traffic.
2.2. Component Repair
Micro-loops may form when a component is (re)introduced into a
network. All of the known loop-free convergence methods are capable
of avoiding such micro-loops. It is not necessary to employ any
repair mechanism to take advantage of this facility, because the
Bryant, Shand Expires Dec 2005 [Page 4]
INTERNET DRAFT A Framework for Loop-free Convergence Jun 2005
new component may be used to provide connectivity before its
presence is made known to the rest of the network.
2.3. Management withdrawal of a component
From the perspective of the routing protocol, management withdrawal
of a component is indistinguishable from an unexpected component
failure, and will be subject to the same micro-loops. The network
will therefore benefit from the use of a micro-loop prevention
mechanism.
Unlike the failure case the component being withdrawn may be used
to forward packets during the transition, and therefore no repair
mechanism is needed.
Unlike the case of component failure or repair, management
withdrawal of a component is normally not time critical.
Consideration may therefore be given to the use of the incremental
cost change loop-free convergence mechanism. This mechanism was
discarded as a candidate in the case of fast re-route because of
its slow time to converge, however it is a mechanism that is
backwards compatible with existing routers and may therefore be of
use in this application.
2.4. Management Insertion of a Component
From the perspective of the routing protocol, management insertion
of a component is indistinguishable from component repair, and will
be subject to the same micro-loops. The network will therefore
benefit from the use of a micro-loop prevention mechanism. No
repair mechanism is needed and is not normally time critical.
2.5. Management Change of a Link Cost
Component failure and component repair are extreme examples of cost
change. Micro-loops may also form when a link cost is changed (in
either direction) during the process of network re-configuration.
The use of a loop-free convergence technique prevents the formation
of micro-loops during this otherwise benign process. No repair
mechanism is needed in this case, because the link is still
available for use.
2.6. External Cost Change
An external cost change can result in a change to the preferred
external route to a destination. Micro-loops may form during the
process of switching from the old boarder router to the new one.
The loop-free control of this change will prevent the loss of
packets during this network transition.
Bryant, Shand Expires Dec 2005 [Page 5]
INTERNET DRAFT A Framework for Loop-free Convergence Jun 2005
2.7. MPLS Applicability
Where the network is an MPLS enabled network using the LDP protocol
to learn labels, and fast re-route is provided through the use of
single hop MPLS-TE tunnels protected by MPLS-TE fast reroute, micro
loops may form during convergence. Loop free convergence is
therefore applicable to this network configuration.
2.8. Routing Vector and Path Vector Convergence
The work to date on controlled convergence has focused on link
state IGPs. The ability to control the convergence of routing
vector and path vector routing protocols would also be useful tools
in the management of the Internet.
At the time of writing however no suitable mechanism has been
proposed.
3. IANA considerations
There are no IANA considerations that arise from this draft.
4. Security Considerations
All micro-loop control mechanisms raise significant security issues
which must be addressed in their detailed technical description.
5. Intellectual Property Statement
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.
Bryant, Shand Expires Dec 2005 [Page 6]
INTERNET DRAFT A Framework for Loop-free Convergence Jun 2005
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.
6. 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.
7. Normative References
There are no normative references.
8. Informative References
Internet-drafts are works in progress available from
<http://www.ietf.org/internet-drafts/>
[IPFRR] Shand, M., "IP Fast-reroute Framework",
<draft-ietf-rtgwg-ipfrr-framework-01.txt>, June
2004, (work in progress).
[RFC3036] Andersson, L., Doolan, P., Feldman, N.,
Fredette, A. and B. Thomas, "LDP
Specification", RFC 3036,
January 2001.
[MPLS-TE] Ping Pan, et al, "Fast Reroute Extensions to
RSVP-TE for LSP Tunnels",
<draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt>,
(work in progress).
Bryant, Shand Expires Dec 2005 [Page 7]
INTERNET DRAFT A Framework for Loop-free Convergence Jun 2005
[LFFWK] Bryant, S., Shand, M., A Framework for Loop-
free Convergence <draft-bryant-shand-lf-conv-
frmwk-00.txt>, (work on progress)
[ZININ] Zinin, A., "Analysis and Minimization of
Microloops in Link-state Routing Protocols",
<draft-zinin-microloop-analysis-01.txt>, May
2005 (work in progress).
9. Authors' Addresses
Mike Shand
Cisco Systems,
250, Longwater,
Green Park,
Reading, RG2 6GB,
United Kingdom. Email: mshand@cisco.com
Stewart Bryant
Cisco Systems,
250, Longwater,
Green Park,
Reading, RG2 6GB,
United Kingdom. Email: stbryant@cisco.com
Bryant, Shand Expires Dec 2005 [Page 8]