idnits 2.17.1 draft-li-rtgwg-enhanced-ti-lfa-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1865 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Adjacency' is mentioned on line 90, but not defined == Missing Reference: 'Node' is mentioned on line 90, but not defined == Unused Reference: 'RFC4657' is defined on line 363, but no explicit reference was found in the text == Unused Reference: 'RFC8253' is defined on line 368, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6571 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-01 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-22 == Outdated reference: A later version (-07) exists of draft-li-ospf-ospfv3-srv6-extensions-03 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG Working Group C. Li 3 Internet-Draft Z. Hu 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 12, 2019 March 11, 2019 7 Enhanced Topology Independent Loop-free Alternate Fast Re-route 8 draft-li-rtgwg-enhanced-ti-lfa-00 10 Abstract 12 Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) aims 13 at providing protection of node and adjacency segments within the 14 Segment Routing (SR) framework. A key aspect of TI-LFA is the FRR 15 path selection approach establishing protection over the expected 16 post-convergence paths from the point of local repair. However, the 17 TI-LFA FRR path may skip the node even if it is specified in the SID 18 list to be traveled. 20 This document defines Enhanced TI-LFA(TI-LFA+) by adding a No-bypass 21 indicator for segments to ensure that the FRR route will not bypass 22 the specific node, such as firewall. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 12, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 3. Overview of Enhanced TI-LFA . . . . . . . . . . . . . . . . . 3 62 4. IGP Protocol Extensions . . . . . . . . . . . . . . . . . . . 4 63 4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 7.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 Segment Routing [RFC8402] enables to steer packets by explicitly 75 encoding instructions in the data packets at the source node to 76 support services like traffic engineer. Relying on SR, 77 [I-D.ietf-rtgwg-segment-routing-ti-lfa] defines Topology Independent 78 Loop-free Alternate Fast Re-route (TI-LFA), a local repair mechanism 79 for IGP shortest path that capable of restoring end-to-end 80 connectivity in the case of a sudden directly connected failure of a 81 network component. 83 TI-LFA supports to establish a loop free backup path over the 84 expected post-convergence paths from the point of local repair 85 irrespective of the topologies used in the network, which provides a 86 major improvment compared to LFA [RFC5286], and remote LFA [RFC7490] 87 which cannot be applicable in some topologies [RFC6571]. 89 However, the TI-LFA path may skip the node that the active SID points 90 to when protecting [Adjacency, Node] segment lists. For instance, 91 the node that a adjacency SID points to is a very important node and 92 can not be skipped, such as a firewall node. When the link between 93 the local repair node and firewall node fails, the packets should be 94 steered back to the firewall and then forwarding. But in TI-LFA, if 95 the next SID in the SID list is a node SID, the TI-LFA FRR path MAY 96 bypass the node that the active segment points to. Also, if the 97 firewall node is down, the packets should be dropped instead for fast 98 reroute to bypass the node. Bypassing nodes like firewall in FRR 99 brings issues of network security and reliability. 101 To enhance the security and reliability of networks, this document 102 defines an Enhanced Topology Independent Loop-free Alternate Fast Re- 103 route (TI-LFA+) based on TI-LFA by adding a No-bypass flag for 104 segments to explicitly specify what node can not be bypassed. 106 2. Terminology 108 This document makes use of the terms defined in 109 [I-D.ietf-rtgwg-segment-routing-ti-lfa] and [RFC8402]. The reader is 110 assumed to be familiar with the terminology defined in 111 [I-D.ietf-rtgwg-segment-routing-ti-lfa] and [RFC8402]. 113 2.1. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 3. Overview of Enhanced TI-LFA 123 Enhanced Topology Independent Loop-free Alternate Fast Re-route (TI- 124 LFA+) is an enhancement of TI-LFA to explicitly indicate whether a 125 node that segment points to can not be bypassed in FRR scenarios. 127 TI-LFA+ will not change the main process and algorithm of TI-LFA. 128 Instead, in TI-LFA+, when generating repair SID list for a SID, the 129 node should consider whether the SID endpoint can be baseed or not, 130 which is explicitly encoded in IGP messages. If the node that 131 segment points to can not be bypassed, then the repair SID MUST lead 132 the packets to that node. This document defines a No-bypass flag for 133 segments in IS-IS and OSPF. Details will be discussed in section 4. 135 A node should advertise two kinds of segment to meet various service 136 policy requirements. 138 o Bypassing capable segment with No-bypass flag unset 140 o No-bypassing segment with No-bypass flag set. 142 A controller or control plane should choose specific segment 143 according to the service policy. 145 4. IGP Protocol Extensions 147 4.1. IS-IS 149 [I-D.ietf-isis-segment-routing-extensions] describes the necessary 150 IS-IS extensions that need to be introduced for Segment 151 Routing.[I-D.bashandy-isis-srv6-extensions] defines the IS-IS 152 extensions required to support Segment Routing over an IPv6 data 153 plane. This documment defines a No-bypass flag in flag filed of the 154 following IS-IS sub-TLV/TLV. 156 o Prefix Segment Identifier sub-TLV (Prefix-SID sub-TLV) 157 [I-D.ietf-isis-segment-routing-extensions] 159 o Adjacency Segment Identifier sub- TLV (Adj-SID sub- 160 TLV).[I-D.ietf-isis-segment-routing-extensions] 162 o Locator entry in SRv6 Locator TLV 163 [I-D.bashandy-isis-srv6-extensions] 165 The following figures are included here for reference and will be 166 deleted in the future version. 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Type | Length | Flags | Algorithm | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | SID/Index/Label (variable) | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 0 1 2 3 4 5 6 7 177 +--+--+--+--+--+--+--+--+ 178 |R | N| P| E| V| L|NB| | 179 +--+--+--+--+--+--+--+--+ 181 Figure 1. Prefix-SID sub-TLV and No-bypass Flag 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Type | Length | Flags | Weight | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | SID/Label/Index (variable) | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 0 1 2 3 4 5 6 7 192 +--+--+--+--+--+--+--+--+ 193 |F | B| V| L| S|NB| | | 194 +--+--+--+--+--+--+--+--+ 195 Figure 2. Adj-SID sub-TLV and No-bypass Flag 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Metric | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Flags | Algorithm | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Loc Size | Locator (variable)... 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Sub-tlv-len | Sub-TLVs (variable) . . . | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 0 1 2 3 4 5 6 7 210 +--+--+--+--+--+--+--+--+ 211 |D |NB| | | | | | | 212 +--+--+--+--+--+--+--+--+ 213 Figure 3. SRv6 Locator Entry and No-bypass Flag 215 If the No-bypass(NB) flag is set, means the node that the SID/Label/ 216 Locator points to can not be bypassed. Oterwise, the node can be 217 bypassed. 219 4.2. OSPF 221 [I-D.ietf-ospf-segment-routing-extensions] describes the necessary 222 OSPF extensions that need to be introduced for Segment 223 Routing.[I-D.li-ospf-ospfv3-srv6-extensions] defines the OSPF 224 extensions required to support Segment Routing over an IPv6 data 225 plane. This documment defines a No-bypass flag in flag filed of the 226 following OSPF sub-TLV/TLV. 228 o Prefix SID Sub-TLV [I-D.ietf-ospf-segment-routing-extensions] 230 o Adj-SID sub-TLV [I-D.ietf-ospf-segment-routing-extensions] 231 o SRv6 Node SID TLV [I-D.li-ospf-ospfv3-srv6-extensions] 233 o SRv6 SID Link Attribute Sub-TLV 234 [I-D.li-ospf-ospfv3-srv6-extensions] 236 The following figures are included here for reference and will be 237 deleted in the future version. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Type | Length | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Flags | Reserved | MT-ID | Algorithm | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | SID/Index/Label (variable) | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 0 1 2 3 4 5 6 7 250 +--+--+--+--+--+--+--+--+ 251 | |NP|M |E |V |L |NB| | 252 +--+--+--+--+--+--+--+--+ 254 Figure 4. Prefix-SID sub-TLV and No-bypass Flag 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Type | Length | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Flags | Reserved | MT-ID | Weight | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | SID/Label/Index (variable) | 264 +---------------------------------------------------------------+ 266 0 1 2 3 4 5 6 7 267 +--+--+--+--+--+--+--+--+ 268 |B | V| L| G| P|NB| | | 269 +--+--+--+--+--+--+--+--+ 271 Figure 5. Adj-SID sub-TLV and No-bypass Flag 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Type | Length | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Reserved | Function-Flags| Function Code | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Reserved | SID Flags | SID-size | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | SID (variable - 32 bit aligned) ... 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Sub-TLVs (variable) . . . 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 0 1 2 3 4 5 6 7 288 +--+--+--+--+--+--+--+--+ 289 |D |NB| | | | | | | 290 +--+--+--+--+--+--+--+--+ 291 Figure 6. SRv6 Node SID TLV and No-bypass Flag 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Type | Length | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Reserved | Function-Flags| Function Code | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Reserved | SID Flags | SID-size | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | SID (variable - 32 bit aligned) ... 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Sub-TLVs (variable) . . . 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 0 1 2 3 4 5 6 7 308 +--+--+--+--+--+--+--+--+ 309 |NB| | | | | | | | 310 +--+--+--+--+--+--+--+--+ 311 Figure 7. SRv6 Adj-SID TLV and No-bypass Flag 313 If the No-bypass(NB) flag is set, means the node that the SID/Label/ 314 Locator points to can not be bypassed. Oterwise, the node can be 315 bypassed. 317 5. IANA Considerations 319 TBD. 321 6. Security Considerations 323 TBD. 325 7. References 327 7.1. Normative References 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, 331 DOI 10.17487/RFC2119, March 1997, 332 . 334 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 335 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 336 DOI 10.17487/RFC5286, September 2008, 337 . 339 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 340 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 341 May 2017, . 343 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 344 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 345 RFC 7490, DOI 10.17487/RFC7490, April 2015, 346 . 348 [RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene, 349 B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free 350 Alternate (LFA) Applicability in Service Provider (SP) 351 Networks", RFC 6571, DOI 10.17487/RFC6571, June 2012, 352 . 354 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 355 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 356 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 357 Camarillo, "Topology Independent Fast Reroute using 358 Segment Routing", draft-ietf-rtgwg-segment-routing-ti- 359 lfa-01 (work in progress), March 2019. 361 7.2. Informative References 363 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 364 Element (PCE) Communication Protocol Generic 365 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 366 2006, . 368 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 369 "PCEPS: Usage of TLS to Provide a Secure Transport for the 370 Path Computation Element Communication Protocol (PCEP)", 371 RFC 8253, DOI 10.17487/RFC8253, October 2017, 372 . 374 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 375 Decraene, B., Litkowski, S., and R. Shakir, "Segment 376 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 377 July 2018, . 379 [I-D.ietf-isis-segment-routing-extensions] 380 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 381 Gredler, H., and B. Decraene, "IS-IS Extensions for 382 Segment Routing", draft-ietf-isis-segment-routing- 383 extensions-22 (work in progress), December 2018. 385 [I-D.ietf-ospf-segment-routing-extensions] 386 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 387 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 388 Extensions for Segment Routing", draft-ietf-ospf-segment- 389 routing-extensions-27 (work in progress), December 2018. 391 [I-D.li-ospf-ospfv3-srv6-extensions] 392 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 393 "OSPFv3 Extensions for SRv6", draft-li-ospf- 394 ospfv3-srv6-extensions-03 (work in progress), March 2019. 396 [I-D.bashandy-isis-srv6-extensions] 397 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 398 Z. Hu, "IS-IS Extensions to Support Routing over IPv6 399 Dataplane", draft-bashandy-isis-srv6-extensions-05 (work 400 in progress), March 2019. 402 Authors' Addresses 403 Cheng Li 404 Huawei Technologies 405 Huawei Campus, No. 156 Beiqing Rd. 406 Beijing 100095 407 China 409 Email: chengli13@huawei.com 411 Zhibo Hu 412 Huawei Technologies 413 Huawei Campus, No. 156 Beiqing Rd. 414 Beijing 100095 415 China 417 Email: huzhibo@huawei.com