Internet DRAFT - draft-bashandy-rtgwg-segment-routing-uloop
draft-bashandy-rtgwg-segment-routing-uloop
Network Working Group Ahmed Bashandy
Internet Draft Clarence Filsfils
Intended status: Standards Track Stephane Litkowski
Expires: June 2024 Cisco Systems, Inc.
Bruno Decraene
Orange
Pierre Francois
INSA Lyon
Peter Psenak
Cisco Systems
December 17, 2023
Loop avoidance using Segment Routing
draft-bashandy-rtgwg-segment-routing-uloop-16
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative
works of it may not be created outside the IETF Standards Process,
except to format it for publication as an RFC or to translate it
into languages other than English.
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."
Bashandy Expires June 17, 2024 [Page 1]
Internet-Draft SR Loop Avoidance December 2023
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 June 17, 2024.
Copyright Notice
Copyright (c) 2023 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 the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction...................................................2
1.1. Conventions used in this document.........................4
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. No impact on capacity planning............................5
5. Security Considerations........................................6
6. IANA Considerations............................................6
7. Contributors...................................................6
8. References.....................................................6
8.1. Normative References......................................6
8.2. Informative References....................................6
9. Acknowledgments................................................6
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.
Bashandy Expires June 17, 2024 [Page 2]
Internet-Draft SR Loop Avoidance December 2023
This document provides a mechanism leveraging SR-MPLS and/or SRv6 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, and
all links have symmetric metrics. 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
(predictability 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
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.
Bashandy Expires June 17, 2024 [Page 3]
Internet-Draft SR Loop Avoidance December 2023
1.1. 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
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to
be interpreted as carrying RFC-2119 significance.
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 predetermined
amount of time C, R installs a FIB entry for D that steers packets
to D via a loop-free SR path. C should be greater than or equal to
the worst-case convergence time of a node, network-wide. The
determination of "C" is outside the scope of this document. 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.
Bashandy Expires June 17, 2024 [Page 4]
Internet-Draft SR Loop Avoidance December 2023
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. TI-LFA Repair Tunnel
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.
4.2. 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.
Bashandy Expires June 17, 2024 [Page 5]
Internet-Draft SR Loop Avoidance December 2023
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. The behavior is local. Nothing is expected from
remote nodes except the basic support of Prefix and Adjacency SID's.
5. Security Considerations
The behavior described in this document is internal functionality
to a router that result in the ability to explicitly steer traffic
over the post convergence path after a remote topology change in a
manner that guarantees loop freeness. Because the behavior serves
to minimize the disruption associated with a topology changes, it
can be seen as a modest security enhancement.
6. IANA Considerations
No requirements for IANA
7. Contributors
Additional contributors: Bruno Decraene and Peter Psenak.
8. References
8.1. Normative References
8.2. Informative References
[1] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and
Shakir, R., "Segment Routing Architecture", draft-ietf-spring-
segment-routing-11 (work in progress), November 2016.
[2] Shand, M. and Bryant, S., "IP Fast Reroute Framework", RFC
5714, January 2010.
[3] Litkowski, S., "Avoiding micro-loops using Segment Routing",
MPLS World Congress , 2016.
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Bashandy Expires June 17, 2024 [Page 6]
Internet-Draft SR Loop Avoidance December 2023
Authors' Addresses
Ahmed Bashandy
Cisco
Email: abashandy.ietf@gmail.com
Clarence Filsfils
Cisco Systems
Brussels, Belgium
Email: cfilsfil@cisco.com
Stephane Litkowski
Cisco
Email: slitkows.ietf@gmail.com
Bruno Decraene
Orange
Email: bruno.decraene@orange.com
Pierre Francois
INSA Lyon
Email: pierre.francois@insa-lyon.fr
Peter Psenak
Cisco System
Email: ppsenak@cisco.com
Bashandy Expires June 17, 2024 [Page 7]
