Network Working Group Pierre Francois
Internet-Draft Clarence Filsfils
Intended status: Standards Track Ahmed Bashandy
Expires: December 12, 2016 Cisco Systems, Inc.
Stephane Litkowski
Orange
June 10, 2016
Loop avoidance using Segment Routing
draft-francois-rtgwg-segment-routing-uloop-00
Abstract
This document presents a mechanism aimed at providing loop avoidance
in the case of IGP network convergence event. The solution relies on
the temporary use of SR policies ensuring loop-freeness over the
post-convergence paths from the converging node to the destination.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 12, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Pierre Francois, et al. Expires December 12, 2016 [Page 1]
Internet-Draft SR Loop Avoidance June 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Loop-free two-stage convergence process . . . . . . . . . . . . 4
3. Computing loop-avoiding SR policies . . . . . . . . . . . . . . 5
4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Incremental deployment . . . . . . . . . . . . . . . . . . 5
4.2. Seamless deployment . . . . . . . . . . . . . . . . . . . . 6
4.3. No impact on capacity planning . . . . . . . . . . . . . . 6
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Pierre Francois, et al. Expires December 12, 2016 [Page 2]
Internet-Draft SR Loop Avoidance June 2016
1. Introduction
Forwarding loops happen during the convergence of the IGP, as a
result of transient inconsistency among forwarding states of the
nodes of the network.
This document provides a mechanism leveraging Segment Routing to
ensure loop-freeness during the IGP reconvergence process following a
link-state change event.
We use Figure 1 to illustrate the mechanism. In this scenario, all
the IGP link metrics are 1, excepted R3-R4 whose metric is 100. We
consider the traffic from S to D.
+-------R1------R2---+
/ \
/ \
S---R0 R3-----D
\ /
\ /
+-------R5------R4---+
100
Figure 1: Illustrative scenario, failure of link R2-R3
When the link between R2 and R3 fails, traffic sent from S to D,
initially flowing along S-R0-R1-R2-R3-D is subject to transient
forwarding loops while routers update their forwarding state for
destination D. For example, if R0 updates its FIB before R5, packets
for D may loop between R0 and R5. If R5 updates its FIB before R4,
packets for D may loop between R5 and R4.
Using segment routing, a headend can enforce an explicit path without
creating any state along the desired path. As a result, a converging
node can enforce traffic on the post-convergence path in a loop-free
manner, using a list of segments (typically short). We suggest that
the converging node enforces its post-convergence path to the
destination when applying this behavior to ease operation
(predicatibility of path, less capacity planning issues ...); nodes
converge over their new optimal path, but temporarily use an SR
policy to ensure loop-freeness over that path.
In our example, R0 can temporarily steer traffic destined to D over
Pierre Francois, et al. Expires December 12, 2016 [Page 3]
Internet-Draft SR Loop Avoidance June 2016
SR path [NodeSID(R4), AdjSID(R4->R3), D]. By doing so, packets for D
will be forwarded by R5 as per NodeSID(R4), and by R4 as per
AdjSID(R4->R3). From R3 on, the packet is forwarded as per
destination D. As a result, traffic follows the desired path,
regardless of the forwarding state for destination D at R5 and R4.
After some time, the normal forwarding behavior (without using an SR
policy) can be applied; routers will converge to their final
forwarding state, still consistently forwarding along the post-
convergence paths across the network.
2. Loop-free two-stage convergence process
Upon a topology change, when a node R converging for destination D
does not trust the loop-freeness of its post-convergence path for
destination D, it applies the following two-stage convergence process
for destination D.
Stage 1: After computing the new path to D, for a configured amount
of time C, R installs a FIB entry for D that steers packets to D via
a loop-free SR path. C is assumed to be configured as per the worst-
case convergence time of a node, network-wide. The SR path is
computed when the event occurs.
Stage 2: After C elapses, R installs the normal post-convergence FIB
entry for D, i.e. without any additional segments inserted that
ensure the loop-free property.
Loop-freeness is ensured during this process, because:
1. Paths made of non up-to-date routers are loop-free.
Routers which forward as per the initial state of the network are
consistent.
2. A packet reaching a node in stage 1 is ensured to reach its
destination.
When a packet reaches a router in stage 1, it is steered on a SR path
ensuring a loop-free post-convergence path, whatever the state of
other routers on the path.
3. Paths made of a mix of routers in stage 1 and stage 2 are
consistent.
After C milliseconds, all routers are forwarding as per their post-
convergence paths, either expressed classically or as a loop-free SR
path.
Pierre Francois, et al. Expires December 12, 2016 [Page 4]
Internet-Draft SR Loop Avoidance June 2016
In our example, when R2-R3 fails, R0 forwards traffic for destination
D over SR Path [NodeSID(R4), AdjSID(R4->R3), D], for C milliseconds.
During that period, packets sent by R0 to D are loop-free as per the
application of the policy. When C elapses, R0 now uses its normal
post-convergence path to the destination, forwarding packets for D as
is to R5.
R5 also implements loop avoidance, and has thus temporarily used a
loop-avoiding SR policy for D. This policy is [AdjSID(R4->R3), D],
oif R5->R4. If R5 is still applying the stage 1 behavior, the packet
will be forwarded using this policy, and will thus safely reach the
destination. If R5 also had moved to stage 2, it forwards the packet
as per its normal post-convergence path, via R4. The forwarding
state of R4 for D at stage 1 and stage 2 are the same: oif R4->R3, as
forwarding packets for destination D as is to R3 ensures a loop-free
post-convergence path.
3. Computing loop-avoiding SR policies
The computation to turn a post-convergence path into a loop-free list
of segments is outside the scope of this document. It is a local
behavior at a node.
In a future revision of this document, we may provide a reference
approach to compute loop-avoiding policies for link up, link metric
increase, link down, link metric decrease, node up, and node down
events.
4. Analysis
In this section, we review the main characteristics of the proposed
solution. These characteristics are illustrated in [3].
4.1. Incremental deployment
There is no requirement for a full network upgrade to get benefits
from the solution.
(1) Nodes that are upgraded bring benefit for the traffic passing
through them.
(2) Nodes that are not upgraded to support SR-based loop-avoidance
will cause the micro-loops that they were causing before, unless they
get avoided by the local behavior of a node supporting the behavior.
Pierre Francois, et al. Expires December 12, 2016 [Page 5]
Internet-Draft SR Loop Avoidance June 2016
4.2. Seamless deployment
The behavior is local. Nothing is expected from remote nodes except
the basic support of Prefix and Adjacency SID's.
4.3. No impact on capacity planning
By ensuring loop-free post-convergence paths, the behavior remains in
line with the natural expected convergence process of the IGP.
Enabling SR-based loop-avoidance hence does not require consideration
for capacity planning, compared to any loop avoidance mechanism that
lets traffic follow a different path than the post-convergence one.
5. Contributors
Additional contributors: Bruno Decraene and Peter Psenak.
6. References
[1] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R.
Shakir, "Segment Routing Architecture",
draft-ietf-spring-segment-routing-07 (work in progress),
December 2015.
[2] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714,
January 2010.
[3] Litkowski, S., "Avoiding micro-loops using Segment Routing",
MPLS World Congress , 2016.
Authors' Addresses
Pierre Francois
Cisco Systems, Inc.
Vimercate
IT
Email: pifranco@cisco.com
Pierre Francois, et al. Expires December 12, 2016 [Page 6]
Internet-Draft SR Loop Avoidance June 2016
Clarence Filsfils
Cisco Systems, Inc.
Brussels
BE
Email: cfilsfil@cisco.com
Ahmed Bashandy
Cisco Systems, Inc.
San Jose
US
Email: bashandy@cisco.com
Stephane Litkowski
Orange
Email: stephane.litkowski@orange.com
Pierre Francois, et al. Expires December 12, 2016 [Page 7]