draft-ietf-rtgwg-segment-routing-ti-lfa-04.txt   draft-ietf-rtgwg-segment-routing-ti-lfa-05.txt 
Network Working Group S. Litkowski Network Working Group S. Litkowski
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track A. Bashandy Intended status: Standards Track A. Bashandy
Expires: March 4, 2021 Individual Expires: May 19, 2021 Individual
C. Filsfils C. Filsfils
Cisco Systems Cisco Systems
B. Decraene B. Decraene
Orange Orange
P. Francois
INSA Lyon
D. Voyer D. Voyer
Bell Canada Bell Canada
F. Clad November 15, 2020
P. Camarillo
Cisco Systems
August 31, 2020
Topology Independent Fast Reroute using Segment Routing Topology Independent Fast Reroute using Segment Routing
draft-ietf-rtgwg-segment-routing-ti-lfa-04 draft-ietf-rtgwg-segment-routing-ti-lfa-05
Abstract Abstract
This document presents Topology Independent Loop-free Alternate Fast This document presents Topology Independent Loop-free Alternate Fast
Re-route (TI-LFA), aimed at providing protection of node and Re-route (TI-LFA), aimed at providing protection of node and
adjacency segments within the Segment Routing (SR) framework. This adjacency segments within the Segment Routing (SR) framework. This
Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being
LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding
(DLFA). It extends these concepts to provide guaranteed coverage in (DLFA). It extends these concepts to provide guaranteed coverage in
any IGP network. A key aspect of TI-LFA is the FRR path selection any IGP network. A key aspect of TI-LFA is the FRR path selection
skipping to change at page 2, line 4 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on March 4, 2021.
This Internet-Draft will expire on May 19, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Conventions used in this document . . . . . . . . . . . . 8 2.1. Conventions used in this document . . . . . . . . . . . . 8
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Intersecting P-Space and Q-Space with post-convergence paths 9 4. Intersecting P-Space and Q-Space with post-convergence paths 9
4.1. P-Space property computation for a resource X . . . . . . 9 4.1. P-Space property computation for a resource X . . . . . . 9
4.2. Q-Space property computation for a link S-F, over post- 4.2. Q-Space property computation for a link S-F, over post-
convergence paths . . . . . . . . . . . . . . . . . . . . 9 convergence paths . . . . . . . . . . . . . . . . . . . . 9
4.3. Q-Space property computation for a set of links adjacent 4.3. Q-Space property computation for a set of links adjacent
to S, over post-convergence paths . . . . . . . . . . . 10 to S, over post-convergence paths . . . . . . . . . . . 9
4.4. Q-Space property computation for a node F, over post- 4.4. Q-Space property computation for a node F, over post-
convergence paths . . . . . . . . . . . . . . . . . . . . 10 convergence paths . . . . . . . . . . . . . . . . . . . . 10
4.5. Scaling considerations when computing Q-Space . . . . . . 10 4.5. Scaling considerations when computing Q-Space . . . . . . 10
5. TI-LFA Repair path . . . . . . . . . . . . . . . . . . . . . 10 5. TI-LFA Repair path . . . . . . . . . . . . . . . . . . . . . 10
5.1. FRR path using a direct neighbor . . . . . . . . . . . . 11 5.1. FRR path using a direct neighbor . . . . . . . . . . . . 10
5.2. FRR path using a PQ node . . . . . . . . . . . . . . . . 11 5.2. FRR path using a PQ node . . . . . . . . . . . . . . . . 11
5.3. FRR path using a P node and Q node that are adjacent . . 11 5.3. FRR path using a P node and Q node that are adjacent . . 11
5.4. Connecting distant P and Q nodes along post-convergence 5.4. Connecting distant P and Q nodes along post-convergence
paths . . . . . . . . . . . . . . . . . . . . . . . . . . 11 paths . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Building TI-LFA repair lists . . . . . . . . . . . . . . . . 11 6. Building TI-LFA repair lists . . . . . . . . . . . . . . . . 11
6.1. Link protection . . . . . . . . . . . . . . . . . . . . . 12 6.1. Link protection . . . . . . . . . . . . . . . . . . . . . 11
6.1.1. The active segment is a node segment . . . . . . . . 12 6.1.1. The active segment is a node segment . . . . . . . . 11
6.1.2. The active segment is an adjacency segment . . . . . 12 6.1.2. The active segment is an adjacency segment . . . . . 12
6.2. Protecting SR policy midpoints against node failure . . . 13 6.2. Protecting SR policy midpoints against node failure . . . 13
6.2.1. Protecting {F, T, D} or {S->F, T, D} . . . . . . . . 14 6.2.1. Protecting {F, T, D} or {S->F, T, D} . . . . . . . . 13
6.2.2. Protecting {F, F->T, D} or {S->F, F->T, D} . . . . . 14 6.2.2. Protecting {F, F->T, D} or {S->F, F->T, D} . . . . . 14
6.3. Dataplane specific considerations . . . . . . . . . . . . 15 6.3. Dataplane specific considerations . . . . . . . . . . . . 15
6.3.1. MPLS dataplane considerations . . . . . . . . . . . . 15 6.3.1. MPLS dataplane considerations . . . . . . . . . . . . 15
6.3.2. SRv6 dataplane considerations . . . . . . . . . . . . 16 6.3.2. SRv6 dataplane considerations . . . . . . . . . . . . 15
7. TI-LFA and SR algorithms . . . . . . . . . . . . . . . . . . 16 7. TI-LFA and SR algorithms . . . . . . . . . . . . . . . . . . 16
8. Usage of Adjacency segments in the repair list . . . . . . . 17 8. Usage of Adjacency segments in the repair list . . . . . . . 16
9. Measurements on Real Networks . . . . . . . . . . . . . . . . 17 9. Measurements on Real Networks . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
12. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 22
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
14.1. Normative References . . . . . . . . . . . . . . . . . . 23 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
14.2. Informative References . . . . . . . . . . . . . . . . . 23 15.1. Normative References . . . . . . . . . . . . . . . . . . 23
15.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Acronyms 1. Acronyms
o DLFA: Remote LFA with Directed forwarding. o DLFA: Remote LFA with Directed forwarding.
o FRR: Fast Re-route. o FRR: Fast Re-route.
o IGP: Interior Gateway Protocol. o IGP: Interior Gateway Protocol.
skipping to change at page 22, line 46 skipping to change at page 22, line 33
No requirements for IANA No requirements for IANA
12. Conclusions 12. Conclusions
This document proposes a mechanism that is able to pre-calculate a This document proposes a mechanism that is able to pre-calculate a
backup path for every primary path so as to be able to protect backup path for every primary path so as to be able to protect
against the failure of a directly connected link, node, or SRLG. The against the failure of a directly connected link, node, or SRLG. The
mechanism is able to calculate the backup path irrespective of the mechanism is able to calculate the backup path irrespective of the
topology as long as the topology is sufficiently redundant. topology as long as the topology is sufficiently redundant.
13. Acknowledgments 13. Contributors
In addition to the authors listed on the front page, the following
co-authors have also contributed to this document:
Pierre Francois, INSA Lyon
Francois Clad, Cisco Systems
Pablo Camarillo, Cisco Systems
14. Acknowledgments
We would like to thank Les Ginsberg, Stewart Bryant, Alexander We would like to thank Les Ginsberg, Stewart Bryant, Alexander
Vainsthein, Chris Bowers, Shraddha Hedge for their valuable comments. Vainsthein, Chris Bowers, Shraddha Hedge for their valuable comments.
14. References 15. References
14.1. Normative References 15.1. Normative References
[I-D.ietf-spring-srv6-network-programming] [I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming", Matsushima, S., and Z. Li, "SRv6 Network Programming",
draft-ietf-spring-srv6-network-programming-18 (work in draft-ietf-spring-srv6-network-programming-24 (work in
progress), August 2020. progress), October 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., [RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K.,
Horneffer, M., and P. Sarkar, "Operational Management of Horneffer, M., and P. Sarkar, "Operational Management of
Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916,
July 2016, <https://www.rfc-editor.org/info/rfc7916>. July 2016, <https://www.rfc-editor.org/info/rfc7916>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
14.2. Informative References 15.2. Informative References
[I-D.bashandy-rtgwg-segment-routing-uloop] [I-D.bashandy-rtgwg-segment-routing-uloop]
Bashandy, A., Filsfils, C., Litkowski, S., Decraene, B., Bashandy, A., Filsfils, C., Litkowski, S., Decraene, B.,
Francois, P., and P. Psenak, "Loop avoidance using Segment Francois, P., and P. Psenak, "Loop avoidance using Segment
Routing", draft-bashandy-rtgwg-segment-routing-uloop-09 Routing", draft-bashandy-rtgwg-segment-routing-uloop-09
(work in progress), June 2020. (work in progress), June 2020.
[I-D.ietf-lsr-flex-algo] [I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
algo-10 (work in progress), August 2020. algo-13 (work in progress), October 2020.
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft- P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-08 (work in progress), ietf-spring-segment-routing-policy-09 (work in progress),
July 2020. November 2020.
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286, IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008, DOI 10.17487/RFC5286, September 2008,
<https://www.rfc-editor.org/info/rfc5286>. <https://www.rfc-editor.org/info/rfc5286>.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, DOI 10.17487/RFC5714, January 2010, RFC 5714, DOI 10.17487/RFC5714, January 2010,
<https://www.rfc-editor.org/info/rfc5714>. <https://www.rfc-editor.org/info/rfc5714>.
skipping to change at page 24, line 31 skipping to change at page 24, line 31
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015, RFC 7490, DOI 10.17487/RFC7490, April 2015,
<https://www.rfc-editor.org/info/rfc7490>. <https://www.rfc-editor.org/info/rfc7490>.
Authors' Addresses Authors' Addresses
Stephane Litkowski Stephane Litkowski
Cisco Systems Cisco Systems
France France
Email: slitkows.ietf@gmail.com Email: slitkows@cisco.com
Ahmed Bashandy Ahmed Bashandy
Individual Individual
Email: abashandy.ietf@gmail.com Email: abashandy.ietf@gmail.com
Clarence Filsfils Clarence Filsfils
Cisco Systems Cisco Systems
Brussels Brussels
Belgium Belgium
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Bruno Decraene Bruno Decraene
Orange Orange
Issy-les-Moulineaux Issy-les-Moulineaux
France France
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Pierre Francois
INSA Lyon
Email: pierre.francois@insa-lyon.fr
Daniel Voyer Daniel Voyer
Bell Canada Bell Canada
Canada Canada
Email: daniel.voyer@bell.ca Email: daniel.voyer@bell.ca
Francois Clad
Cisco Systems
Email: fclad@cisco.com
Pablo Camarillo
Cisco Systems
Email: pcamaril@cisco.com
 End of changes. 23 change blocks. 
37 lines changed or deleted 39 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/