< draft-li-rtgwg-enhanced-ti-lfa-05.txt   draft-li-rtgwg-enhanced-ti-lfa-06.txt >
RTGWG Working Group C. Li RTGWG Working Group C. Li
Internet-Draft Z. Hu Internet-Draft Z. Hu
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: April 24, 2022 Y. Zhu Expires: 24 October 2022 Y. Zhu
China Telecom China Telecom
S. Hegde S. Hegde
Juniper Networks Inc. Juniper Networks Inc.
October 21, 2021 22 April 2022
Enhanced Topology Independent Loop-free Alternate Fast Re-route Enhanced Topology Independent Loop-free Alternate Fast Re-route
draft-li-rtgwg-enhanced-ti-lfa-05 draft-li-rtgwg-enhanced-ti-lfa-06
Abstract Abstract
Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) aims Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) aims
at providing protection of node and adjacency segments within the at providing protection of node and adjacency segments within the
Segment Routing (SR) framework. A key aspect of TI-LFA is the FRR Segment Routing (SR) framework. A key aspect of TI-LFA is the FRR
path selection approach establishing protection over the expected path selection approach establishing protection over the expected
post-convergence paths from the point of local repair. However, the post-convergence paths from the point of local repair. However, the
TI-LFA FRR path may skip the node even if it is specified in the SID TI-LFA FRR path may skip the node even if it is specified in the SID
list to be traveled. list to be traveled.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 April 24, 2022. This Internet-Draft will expire on 24 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Overview of Enhanced TI-LFA . . . . . . . . . . . . . . . . . 3 3. Overview of Enhanced TI-LFA . . . . . . . . . . . . . . . . . 3
4. IGP Protocol Extensions . . . . . . . . . . . . . . . . . . . 4 4. IGP Protocol Extensions . . . . . . . . . . . . . . . . . . . 4
4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Flags in SRH . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Flags in SRH . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. No-bypass Flag in SRH . . . . . . . . . . . . . . . . . . 8 5.1. No-bypass Flag in SRH . . . . . . . . . . . . . . . . . . 9
5.2. No-FRR Flag in SRH . . . . . . . . . . . . . . . . . . . 9 5.2. No-FRR Flag in SRH . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Segment Routing [RFC8402] enables to steer packets by explicitly Segment Routing [RFC8402] enables to steer packets by explicitly
encoding instructions in the data packets at the source node to encoding instructions in the data packets at the source node to
support services like traffic engineer. Relying on SR, support services like traffic engineer. Relying on SR,
[I-D.ietf-rtgwg-segment-routing-ti-lfa] defines Topology Independent [I-D.ietf-rtgwg-segment-routing-ti-lfa] defines Topology Independent
Loop-free Alternate Fast Re-route (TI-LFA), a local repair mechanism Loop-free Alternate Fast Re-route (TI-LFA), a local repair mechanism
skipping to change at page 4, line 11 skipping to change at page 4, line 16
Instead, in TI-LFA+, when generating repair SID list for a SID, the Instead, in TI-LFA+, when generating repair SID list for a SID, the
node should consider whether the SID endpoint can be baseed or not, node should consider whether the SID endpoint can be baseed or not,
which is explicitly encoded in IGP messages. If the node that which is explicitly encoded in IGP messages. If the node that
segment points to can not be bypassed, then the repair SID MUST lead segment points to can not be bypassed, then the repair SID MUST lead
the packets to that node. This document defines a No-bypass flag for the packets to that node. This document defines a No-bypass flag for
segments in IS-IS and OSPF. Details will be discussed in section 4. segments in IS-IS and OSPF. Details will be discussed in section 4.
A node should advertise two kinds of segment to meet various service A node should advertise two kinds of segment to meet various service
policy requirements. policy requirements.
o Bypassing capable segment with No-bypass flag unset * Bypassing capable segment with No-bypass flag unset
o No-bypassing segment with No-bypass flag set. * No-bypassing segment with No-bypass flag set.
A controller or control plane should choose specific segment A controller or control plane should choose specific segment
according to the service policy. according to the service policy.
[Editors' note] If the TI-LFA result is generated based on Locator [Editors' note] If the TI-LFA result is generated based on Locator
route instead of SIDs, then the No-bypass Flag can be applied to the route instead of SIDs, then the No-bypass Flag can be applied to the
Locator. Locator.
Also, this document defines No-bypass flag and No-FRR flag in SRH to Also, this document defines No-bypass flag and No-FRR flag in SRH to
indicate not to bypass nodes and not to perform FRR on all the nodes indicate not to bypass nodes and not to perform FRR on all the nodes
skipping to change at page 4, line 37 skipping to change at page 4, line 42
4. IGP Protocol Extensions 4. IGP Protocol Extensions
4.1. IS-IS 4.1. IS-IS
[RFC8667] describes the necessary IS-IS extensions that need to be [RFC8667] describes the necessary IS-IS extensions that need to be
introduced for Segment Routing.[I-D.ietf-lsr-isis-srv6-extensions] introduced for Segment Routing.[I-D.ietf-lsr-isis-srv6-extensions]
defines the IS-IS extensions required to support Segment Routing over defines the IS-IS extensions required to support Segment Routing over
an IPv6 data plane. This documment defines a No-bypass flag in flag an IPv6 data plane. This documment defines a No-bypass flag in flag
filed of the following IS-IS sub-TLV/TLV. filed of the following IS-IS sub-TLV/TLV.
o Prefix Segment Identifier sub-TLV (Prefix-SID sub-TLV) [RFC8667] * Prefix Segment Identifier sub-TLV (Prefix-SID sub-TLV) [RFC8667]
o Adjacency Segment Identifier sub- TLV (Adj-SID sub-TLV).[RFC8667] * Adjacency Segment Identifier sub- TLV (Adj-SID sub-TLV).[RFC8667]
o Locator entry in SRv6 Locator TLV * Locator entry in SRv6 Locator TLV
[I-D.ietf-lsr-isis-srv6-extensions] [I-D.ietf-lsr-isis-srv6-extensions]
The following figures are included here for reference and will be The following figures are included here for reference and will be
deleted in the future version. deleted in the future version.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | Algorithm | | Type | Length | Flags | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 17 skipping to change at page 6, line 35
bypassed. bypassed.
4.2. OSPF 4.2. OSPF
[RFC8665] describes the necessary OSPF extensions that need to be [RFC8665] describes the necessary OSPF extensions that need to be
introduced for Segment Routing.[I-D.ietf-lsr-ospfv3-srv6-extensions] introduced for Segment Routing.[I-D.ietf-lsr-ospfv3-srv6-extensions]
defines the OSPF extensions required to support Segment Routing over defines the OSPF extensions required to support Segment Routing over
an IPv6 data plane. This documment defines a No-bypass flag in flag an IPv6 data plane. This documment defines a No-bypass flag in flag
filed of the following OSPF sub-TLV/TLV. filed of the following OSPF sub-TLV/TLV.
o Prefix SID Sub-TLV [RFC8665] * Prefix SID Sub-TLV [RFC8665]
o Adj-SID sub-TLV [RFC8665] * Adj-SID sub-TLV [RFC8665]
o SRv6 Node SID TLV [I-D.ietf-lsr-ospfv3-srv6-extensions] * SRv6 Node SID TLV [I-D.ietf-lsr-ospfv3-srv6-extensions]
o SRv6 SID Link Attribute Sub-TLV * SRv6 SID Link Attribute Sub-TLV
[I-D.ietf-lsr-ospfv3-srv6-extensions] [I-D.ietf-lsr-ospfv3-srv6-extensions]
The following figures are included here for reference and will be The following figures are included here for reference and will be
deleted in the future version. deleted in the future version.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 42 skipping to change at page 9, line 18
5.1. No-bypass Flag in SRH 5.1. No-bypass Flag in SRH
This document defines a No-bypass Flag in SRH [RFC8754]. This document defines a No-bypass Flag in SRH [RFC8754].
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
|NB| | | | | | | | |NB| | | | | | | |
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
o NB Flag: No-Bypass flag, when the flag is set, the repair segment * NB Flag: No-Bypass flag, when the flag is set, the repair segment
endpoint nodes MUST NOT bypass any nodes when link or node endpoint nodes MUST NOT bypass any nodes when link or node
failures occur. When a link is down, the packet MUST be forwarded failures occur. When a link is down, the packet MUST be forwarded
to the next segment endpoint node through the repair path. When to the next segment endpoint node through the repair path. When
the node identified by the active SID in IPv6 destination address the node identified by the active SID in IPv6 destination address
is down, the SID can not be skipped, and the traffic MUST be is down, the SID can not be skipped, and the traffic MUST be
forwarded to the node. forwarded to the node.
The flag can be set when the SID list containing service SIDs like The flag can be set when the SID list containing service SIDs like
firewall SID, so that the traffic will not bypass the service nodes. firewall SID, so that the traffic will not bypass the service nodes.
5.2. No-FRR Flag in SRH 5.2. No-FRR Flag in SRH
This document defines a No-FRR Flag in SRH [RFC8754]. This document defines a No-FRR Flag in SRH [RFC8754].
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
| |NF| | | | | | | | |NF| | | | | | |
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
o NF Flag: No-FRR flag, when the flag is set, the FRR is disable for * NF Flag: No-FRR flag, when the flag is set, the FRR is disable for
the packet, thus the packet will not be protected by the Local the packet, thus the packet will not be protected by the Local
protection mechanism, such as TI-LFA. protection mechanism, such as TI-LFA.
The flag can be set when the SID list containing service SIDs like The flag can be set when the SID list containing service SIDs like
firewall SID, so that the traffic will not bypass the service nodes. firewall SID, so that the traffic will not bypass the service nodes.
In this case, E2E protection mechanism should be deployed. In this case, E2E protection mechanism should be deployed.
6. IANA Considerations 6. IANA Considerations
TBD. TBD.
skipping to change at page 10, line 19 skipping to change at page 10, line 41
[RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene, [RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene,
B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free
Alternate (LFA) Applicability in Service Provider (SP) Alternate (LFA) Applicability in Service Provider (SP)
Networks", RFC 6571, DOI 10.17487/RFC6571, June 2012, Networks", RFC 6571, DOI 10.17487/RFC6571, June 2012,
<https://www.rfc-editor.org/info/rfc6571>. <https://www.rfc-editor.org/info/rfc6571>.
[I-D.ietf-rtgwg-segment-routing-ti-lfa] [I-D.ietf-rtgwg-segment-routing-ti-lfa]
Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., Litkowski, S., Bashandy, A., Filsfils, C., Francois, P.,
Decraene, B., and D. Voyer, "Topology Independent Fast Decraene, B., and D. Voyer, "Topology Independent Fast
Reroute using Segment Routing", draft-ietf-rtgwg-segment- Reroute using Segment Routing", Work in Progress,
routing-ti-lfa-07 (work in progress), June 2021. Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-
08, 21 January 2022, <https://www.ietf.org/archive/id/
draft-ietf-rtgwg-segment-routing-ti-lfa-08.txt>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>. <https://www.rfc-editor.org/info/rfc8754>.
8.2. Informative References 8.2. Informative References
[RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation [RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September Requirements", RFC 4657, DOI 10.17487/RFC4657, September
2006, <https://www.rfc-editor.org/info/rfc4657>. 2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the "PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)", Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017, RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>. <https://www.rfc-editor.org/info/rfc8253>.
skipping to change at page 11, line 13 skipping to change at page 11, line 35
<https://www.rfc-editor.org/info/rfc8667>. <https://www.rfc-editor.org/info/rfc8667>.
[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", RFC 8665, Extensions for Segment Routing", RFC 8665,
DOI 10.17487/RFC8665, December 2019, DOI 10.17487/RFC8665, December 2019,
<https://www.rfc-editor.org/info/rfc8665>. <https://www.rfc-editor.org/info/rfc8665>.
[I-D.ietf-lsr-ospfv3-srv6-extensions] [I-D.ietf-lsr-ospfv3-srv6-extensions]
Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak,
"OSPFv3 Extensions for SRv6", draft-ietf-lsr- "OSPFv3 Extensions for SRv6", Work in Progress, Internet-
ospfv3-srv6-extensions-02 (work in progress), February Draft, draft-ietf-lsr-ospfv3-srv6-extensions-03, 19
2021. November 2021, <https://www.ietf.org/archive/id/draft-
ietf-lsr-ospfv3-srv6-extensions-03.txt>.
[I-D.ietf-lsr-isis-srv6-extensions] [I-D.ietf-lsr-isis-srv6-extensions]
Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
Z. Hu, "IS-IS Extensions to Support Segment Routing over Z. Hu, "IS-IS Extensions to Support Segment Routing over
IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-18 IPv6 Dataplane", Work in Progress, Internet-Draft, draft-
(work in progress), October 2021. ietf-lsr-isis-srv6-extensions-18, 20 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-lsr-isis-srv6-
extensions-18.txt>.
Authors' Addresses Authors' Addresses
Cheng Li Cheng Li
Huawei Technologies Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Beijing
100095
China
Email: c.l@huawei.com Email: c.l@huawei.com
Zhibo Hu Zhibo Hu
Huawei Technologies Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095 Beijing
100095
China China
Email: huzhibo@huawei.com Email: huzhibo@huawei.com
Yongqing Zhu Yongqing Zhu
China Telecom China Telecom
Email: zhuyq8@chinatelecom.cn Email: zhuyq8@chinatelecom.cn
Shraddha Hegde Shraddha Hegde
Juniper Networks Inc. Juniper Networks Inc.
India India
Email: shraddha@juniper.net Email: shraddha@juniper.net
 End of changes. 30 change blocks. 
43 lines changed or deleted 47 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/