idnits 2.17.1 draft-chen-idr-sr-ingress-protection-03.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 31, 2020) is 1272 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: 'CE1' is mentioned on line 157, but not defined == Missing Reference: 'CE2' is mentioned on line 157, but not defined == Unused Reference: 'RFC7356' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'I-D.hegde-spring-node-protection-for-sr-te-paths' is defined on line 633, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 645, but no explicit reference was found in the text == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 651, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 662, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-09 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-19 ** Downref: Normative reference to an Experimental RFC: RFC 8424 == Outdated reference: A later version (-24) exists of draft-hu-spring-segment-routing-proxy-forwarding-12 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-08 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Chen 3 Internet-Draft Futurewei 4 Intended status: Standards Track M. Toy 5 Expires: May 4, 2021 Verizon 6 A. Wang 7 China Telecom 8 Z. Li 9 China Mobile 10 L. Liu 11 Fujitsu 12 X. Liu 13 Volta Networks 14 October 31, 2020 16 SR Path Ingress Protection 17 draft-chen-idr-sr-ingress-protection-03 19 Abstract 21 This document describes extensions to Border Gateway Protocol (BGP) 22 for protecting the ingress node of a Segment Routing (SR) tunnel or 23 path. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 4, 2021. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. SR Path Ingress Protection Example . . . . . . . . . . . . . 4 68 4. Behavior after Ingress Failure . . . . . . . . . . . . . . . 4 69 5. Extensions to BGP . . . . . . . . . . . . . . . . . . . . . . 5 70 5.1. SR Path Ingress Protection Sub-TLV . . . . . . . . . . . 5 71 5.1.1. Primary Ingress Sub-TLV . . . . . . . . . . . . . . . 6 72 5.1.2. Service Sub-TLV . . . . . . . . . . . . . . . . . . . 7 73 5.1.3. Traffic Description Sub-TLVs . . . . . . . . . . . . 8 74 6. Backup Ingress Behavior . . . . . . . . . . . . . . . . . . . 11 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 9.1. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . 12 79 9.2. Ingress Protection Information Sub-TLVs . . . . . . . . . 13 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 82 10.2. Informative References . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 The fast protection of a transit node of a Segment Routing (SR) path 88 or tunnel is described in [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 89 and [I-D.hu-spring-segment-routing-proxy-forwarding]. [RFC8424] 90 presents extensions to RSVP-TE for the fast protection of the ingress 91 node of a traffic engineering (TE) Label Switching Path (LSP). 92 However, these documents do not discuss any protocol extensions for 93 the fast protection of the ingress node of an SR path or tunnel. 95 This document fills that void and specifies protocol extensions to 96 Border Gateway Protocol (BGP) for the fast protection of the ingress 97 node of an SR path or tunnel. Ingress node and ingress, fast 98 protection and protection as well as SR path and SR tunnel will be 99 used exchangeably in the following sections. 101 2. Terminologies 103 The following terminologies are used in this document. 105 SR: Segment Routing 107 SRv6: SR for IPv6 109 SRH: Segment Routing Header 111 SID: Segment Identifier 113 CE: Customer Edge 115 PE: Provider Edge 117 LFA: Loop-Free Alternate 119 TI-LFA: Topology Independent LFA 121 TE: Traffic Engineering 123 BFD: Bidirectional Forwarding Detection 125 VPN: Virtual Private Network 127 L3VPN: Layer 3 VPN 129 FIB: Forwarding Information Base 131 PLR: Point of Local Repair 133 BGP: Border Gateway Protocol 135 IGP: Interior Gateway Protocol 137 OSPF: Open Shortest Path First 139 IS-IS: Intermediate System to Intermediate System 141 3. SR Path Ingress Protection Example 143 To protect against the failure of the (primary) ingress node of a 144 (primary) SR path, a backup ingress node is configured or selected 145 and is different from the (primary) ingress node. A backup SR path 146 from the backup ingress node is computed and installed. Primary 147 ingress and ingress as well as primary SR path and SR path will be 148 used exchangeably. 150 Figure 1 shows an example of protecting ingress PE1 of a SR path, 151 which is from ingress PE1 to egress PE3. 153 ******* ******* 154 [PE1]-----[P1]-----[PE3] PE1 Ingress 155 / | |& &&&&& | \ PEx Provider Edge 156 / | |& | \ CEx Customer Edge 157 [CE1] | |& | [CE2] Px Non Provider Edge 158 \ | |& | / *** SR Path 159 \ | &&&&&& |& | / &&& Backup Path 160 [PE2]-----[P2]-----[PE4] 162 Figure 1: Protecting Ingress PE1 of SR Path PE1-P1-PE3 164 In normal operations, CE1 sends the traffic with destination PE3 to 165 ingress PE1, which imports the traffic into the SR path. 167 When CE1 detects the failure of ingress PE1, it switches the traffic 168 to backup ingress PE2, which imports the traffic from CE1 into a 169 backup SR path. The backup path is from the backup ingress PE2 to 170 the egress PE3. When the traffic is imported into the backup path, 171 it is sent to the egress PE3 along the path. 173 4. Behavior after Ingress Failure 175 After the failure of the ingress of an SR path happens, there are a 176 couple of different ways to detect the failure. In each way, there 177 may be some specific behavior for the traffic source (e.g., CE1) and 178 the backup ingress (e.g., PE2). 180 In one way, the traffic source (e.g., CE1) is responsible for fast 181 detecting the failure of the ingress (e.g., PE1) of an SR path. Fast 182 detecting the failure means detecting the failure in a few or tens of 183 milliseconds. The backup ingress (e.g., PE2) is ready to import the 184 traffic from the traffic source into the backup SR path installed. 186 In normal operations, the source sends the traffic to the ingress of 187 the SR path. When the source detects the failure of the ingress, it 188 switches the traffic to the backup ingress, which delivers the 189 traffic to the egress of the SR path via the backup SR path. 191 In another way, the backup ingress is responsible for fast detecting 192 the failure of the ingress of an SR path. 194 In normal operations, the source (e.g., CE1) sends the traffic to the 195 ingress (e.g., PE1) and may send the traffic to the backup ingress 196 (e.g., PE2). It sends the traffic to the backup ingress (e.g., PE2) 197 after the ingress fails. 199 The backup ingress does not import any traffic from the source into 200 the backup SR path in normal operations. When it detects the failure 201 of the ingress, it imports the traffic from the source into the 202 backup SR path. 204 5. Extensions to BGP 206 For a SR path from a primary ingress node to an egress node, a backup 207 ingress node is selected to protect the failure of the primary 208 ingress node of the SR path. This section describes the extensions 209 to BGP for representing the information for protecting the primary 210 ingress node in a BGP UPDATE message and distributing the information 211 to the backup ingress node. The information includes a SR backup 212 path. 214 [I-D.ietf-idr-segment-routing-te-policy] specifies a way of 215 representing a SR path in a BGP UPDATE message and distributing the 216 SR path to the ingress node of the SR path. 218 This is extended to represent the information for protecting the 219 primary ingress by defining a few of new Sub-TLVs. 221 5.1. SR Path Ingress Protection Sub-TLV 223 A new Sub-TLV, called SR Path Ingress Protection Sub-TLV, is defined. 224 When a UPDATE message is sent to the backup ingress node for 225 protecting the primary ingress node of a SR path, the message 226 contains this Sub-TLV. Its format is illustrated below. 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Type (TBD1) | Length (variable) | Flags |A| 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 ~ ~ 234 ~ Sub-TLVs (optional) ~ 235 ~ ~ 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Figure 2: SR Path Ingress Protection Sub-TLV 240 Type: TBD1 is to be assigned by IANA. 242 Length: Variable. 244 Flags: 1 octet. One flag is defined. 246 Flag A: 1 bit. It is set to 248 1: request a backup ingress to let the forwarding entry for the 249 backup SR path be Active. 251 0: request a backup ingress to let the forwarding entry for the 252 backup SR path be inactive initially and to make the entry 253 be active after detecting the failure of the primary ingress 254 node of the primary SR path. 256 A few optional Sub-TLVs are defined, which are Primary Ingress Sub- 257 TLV, Service Sub-TLV and Traffic Description Sub-TLV. 259 5.1.1. Primary Ingress Sub-TLV 261 A Primary Ingress Sub-TLV indicates the IP address of the primary 262 ingress node of a primary SR path. It has two formats: one for 263 primary ingress node IPv4 address and the other for primary ingress 264 node IPv6 address, which are illustrated below. 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Type (1) | Length (4) | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Primary Ingress IPv4 Address (4 octets) | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Figure 3: Primary Ingress IPv4 Address Sub-TLV 276 Type: Its value (1 suggested) is to be assigned by IANA. 278 Length: 4. 280 Primary Ingress IPv4 Address: 4 octets. It represents an IPv4 host 281 address of the primary ingress node of a primary SR path. 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Type (2) | Length (16) | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Primary Ingress IPv6 Address (16 octets) | 289 ~ ~ 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Figure 4: Primary Ingress IPv6 Address Sub-TLV 294 Type: Its value (2 suggested) is to be assigned by IANA. 296 Length: 16. 298 Primary Ingress IPv6 Address: 16 octets. It represents an IPv6 host 299 address of the primary ingress node of a primary SR path. 301 5.1.2. Service Sub-TLV 303 A Service Sub-TLV contains a service ID or label to be added into a 304 packet to be carried by a SR path. It has three formats: the first 305 one for the service identified by a label, the second one for the 306 service identified by a service identifier (ID) of 32 bits, and the 307 third one for the service identified by a service identifier (ID) of 308 128 bits. Their formats are illustrated below. 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Type (3) | Length (4) | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | zero | Service Label (20 bits) | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Figure 5: Service Label Sub-TLV 320 Type: Its value (3 suggested) is to be assigned by IANA. 322 Length: 4. 324 Service Label: the least significant 20 bits. It represents a label 325 of 20 bits. 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Type (4) | Length (4) | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Service ID (4 octets) | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 Figure 6: 32 Bits Service ID Sub-TLV 337 Type: Its value (4 suggested) is to be assigned by IANA. 339 Length: 4. 341 Service ID: 4 octets. It represents a Service Identifier (ID) of 32 342 bits. 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Type (5) | Length (16) | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Service ID (16 octets) | 350 ~ ~ 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Figure 7: 128 Bits Service ID Sub-TLV 355 Type: Its value (5 suggested) is to be assigned by IANA. 357 Length: 16. 359 Service ID: 16 octets. It represents a Service Identifier (ID) of 360 128 bits. 362 5.1.3. Traffic Description Sub-TLVs 364 A Traffic Description Sub-TLV describes the traffic to be imported 365 into a backup SR path. Five Traffic Description Sub-TLVs are 366 defined. Two of them are FEC Sub-TLVs and the others are interface 367 Sub-TLVs. 369 Two FEC Sub-TLVs are IPv4 and IPv6 FEC Sub-TLVs. Their formats are 370 illustrated below. 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Type (6) |Length(variable| 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 |IPv4 Prefix Len| IPv4 Prefix ~ 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 ~ (Optional) Virtual Network ID (2 octets) ~ 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Figure 8: IPv4 FEC Sub-TLV 384 Type: Its value (6 suggested) is to be assigned by IANA. 386 Length: Variable. 388 IPv4 Prefix Len: Indicates the length of the IPv4 Prefix. 390 IPv4 Prefix: IPv4 Prefix rounded to octets. 392 Virtual Network ID: 2 octets. This is optional. It indicates the 393 ID of a virtual network. 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Type (7) |Length(variable| 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 |IPv6 Prefix Len| IPv6 Prefix ~ 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 ~ Optional Virtual Network ID (2 octets) ~ 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Figure 9: IPv6 FEC Sub-TLV 407 Type: Its value (7 suggested) is to be assigned by IANA. 409 Length: Variable. 411 IPv6 Prefix Len: Indicates the length of the IPv6 Prefix. 413 IPv6 Prefix: IPv6 Prefix rounded to octets. 415 Virtual Network ID: 2 octets. This is optional. It indicates the 416 ID of a virtual network. 418 An Interface sub-TLV indicates the interface from which the traffic 419 is received and imported into the backup SR path/tunnel. It has 420 three formats: one for interface index, the other two for IPv4 and 421 IPv6 address, which are illustrated below. 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Type (8) | Length (4) | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Interface Index (4 octets) | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 Figure 10: Interface Index Sub-TLV 433 Type: Its value (8 suggested) is to be assigned by IANA. 435 Length: 4. 437 Interface Index: 4 octets. It indicates the index of an interface. 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Type (9) | Length (4) | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Interface IPv4 Address (4 octets) | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Figure 11: Interface IPv4 Address Sub-TLV 449 Type: Its value (9 suggested) is to be assigned by IANA. 451 Length: 4. 453 Interface IPv4 Address: 4 octets. It represents the IPv4 address of 454 an interface. 456 0 1 2 3 457 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 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Type (10) | Length (16) | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Interface IPv6 Address (16 octets) | 462 ~ ~ 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 Figure 12: Interface IPv6 Address Sub-TLV 467 Type: Its value (10 suggested) is to be assigned by IANA. 469 Length: 16. 471 Interface IPv6 Address: 16 octets. It represents the IPv6 address 472 of an interface. 474 6. Backup Ingress Behavior 476 When a backup ingress node receives a UPDATE message containing the 477 information for protecting the primary ingress node of a SR path, it 478 installs a forwarding entry in its FIB based on the information. The 479 information is encoded in a SR policy of the following structure: 481 SR Policy SAFI NLRI: 482 Attributes: 483 Tunnel Encaps Attribute (23) 484 Tunnel Type (15): SR Policy 485 SR Path Ingress Protection Sub-TLV 486 Primary Ingress Sub-TLV 487 Service Sub-TLV 488 Traffic Description Sub-TLV 489 Preference Sub-TLV 490 Binding SID Sub-TLV 491 Explicit NULL Label Policy (ENLP) Sub-TLV 492 Priority Sub-TLV 493 Policy Name Sub-TLV 494 Segment List Sub-TLV 495 Weight Sub-TLV 496 Segment Sub-TLV 497 Segment Sub-TLV 498 ... 499 ... 501 Where: 503 o SR Policy SAFI NLRI is defined in 504 [I-D.ietf-idr-segment-routing-te-policy]. 506 o Tunnel Encapsulation Attribute is defined in 507 [I-D.ietf-idr-tunnel-encaps]. 509 o Tunnel Type of SR Policy is defined in 510 [I-D.ietf-idr-segment-routing-te-policy]. 512 o SR Path Ingress Protection, Primary Ingress, Service and Traffic 513 Description Sub-TLVs are defined in this document. 515 o Preference, Binding SID, ENLP, Priority, Policy Name, Segment 516 List, Weight and Segment Sub-TLVs are defined in 517 [I-D.ietf-idr-segment-routing-te-policy]. 519 After receiving a SR policy with a SR Path Ingress Protection Sub- 520 TLV, the backup ingress node will install one or more candidate paths 521 into its "BGP table". Another module such as SRPM will choose one or 522 more paths and install the forwarding entries for them in the data 523 plane. 525 The forwarding entries for the paths installed in the data plane will 526 be set to be inactive if the flag A in the SR Path Ingress Protection 527 Sub-TLV is zero. When the primary ingress node fails, these 528 forwarding entries are set to be active. The failure of the primary 529 ingress may be detected by the backup ingress node through using a 530 mechanism such as BFD. The IP address of the primary ingress in the 531 Primary Ingress Sub-TLV may be used for detecting the failure of the 532 primary ingress node. 534 If the flag A in the SR Path Ingress Protection Sub-TLV is one, then 535 the forwarding entries for the paths installed in the data plane will 536 be set to be active. 538 When there is a Service Sub-TLV in the SR Path Ingress Protection 539 Sub-TLV, the ID or Label in the Service Sub-TLV will be included in 540 the forwarding entries. When a packet is imported into a backup SR 541 path using the forwarding entries, the service ID or Label is pushed 542 first and then the sequence of segments represented in the Segment 543 List Sub-TLV. 545 7. Security Considerations 547 Protocol extensions defined in this document do not affect the BGP 548 security other than those as discussed in the Security Considerations 549 section of [RFC5575]. 551 8. Acknowledgements 553 The authors of this document would like to thank Dhruv Dhody for the 554 comments. 556 9. IANA Considerations 558 9.1. BGP Tunnel Encapsulation Attribute Sub-TLVs 560 Under Existing Registry Name: "BGP Tunnel Encapsulation Attribute 561 Sub-TLVs", IANA is requested to assign a new Sub-TLV value for SR 562 Path Ingress Protection as follows: 564 Value sub-TLV Name Reference 565 ----- ------------------------------------ -------------- 566 TBD1 SR Path Ingress Protection Sub-TLV This Document 568 9.2. Ingress Protection Information Sub-TLVs 570 A new registry called "Ingress Protection Information Sub-TLVs" is 571 defined in this document. IANA is requested to create and maintain 572 new registry: 574 o Ingress Protection Information Sub-TLVs 576 Initial values for the registry are given below. The future 577 assignments are to be made through IETF Review [RFC5226]. 579 Value sub-TLV Name Reference 580 ----- ------------------------------------- -------------- 581 0 Reserved 582 1 Primary Ingress IPv4 Address Sub-TLV This Document 583 2 Primary Ingress IPv6 Address Sub-TLV This Document 584 3 Service Label Sub-TLV This Document 585 4 32 Bits Service ID Sub-TLV This Document 586 5 128 Bits Service ID Sub-TLV This Document 587 6 IPv4 FEC Sub-TLV This Document 588 7 IPv6 FEC Sub-TLV This Document 589 8 Interface Index Sub-TLV This Document 590 9 Interface IPv4 Address Sub-TLV This Document 591 10 Interface IPv6 Address Sub-TLV This Document 592 11-255 Unassigned 594 10. References 596 10.1. Normative References 598 [I-D.ietf-idr-segment-routing-te-policy] 599 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 600 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 601 Routing Policies in BGP", draft-ietf-idr-segment-routing- 602 te-policy-09 (work in progress), May 2020. 604 [I-D.ietf-idr-tunnel-encaps] 605 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 606 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 607 encaps-19 (work in progress), September 2020. 609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 610 Requirement Levels", BCP 14, RFC 2119, 611 DOI 10.17487/RFC2119, March 1997, 612 . 614 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 615 Scope Link State PDUs (LSPs)", RFC 7356, 616 DOI 10.17487/RFC7356, September 2014, 617 . 619 [RFC8424] Chen, H., Ed. and R. Torvi, Ed., "Extensions to RSVP-TE 620 for Label Switched Path (LSP) Ingress Fast Reroute (FRR) 621 Protection", RFC 8424, DOI 10.17487/RFC8424, August 2018, 622 . 624 10.2. Informative References 626 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 627 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 628 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 629 Camarillo, "Topology Independent Fast Reroute using 630 Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- 631 lfa-05 (work in progress), October 2018. 633 [I-D.hegde-spring-node-protection-for-sr-te-paths] 634 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 635 "Node Protection for SR-TE Paths", draft-hegde-spring- 636 node-protection-for-sr-te-paths-07 (work in progress), 637 July 2020. 639 [I-D.hu-spring-segment-routing-proxy-forwarding] 640 Hu, Z., Chen, H., Yao, J., Bowers, C., and Y. Zhu, "SR-TE 641 Path Midpoint Protection", draft-hu-spring-segment- 642 routing-proxy-forwarding-12 (work in progress), October 643 2020. 645 [I-D.ietf-spring-segment-routing-policy] 646 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 647 P. Mattes, "Segment Routing Policy Architecture", draft- 648 ietf-spring-segment-routing-policy-08 (work in progress), 649 July 2020. 651 [I-D.sivabalan-pce-binding-label-sid] 652 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 653 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 654 in PCE-based Networks.", draft-sivabalan-pce-binding- 655 label-sid-07 (work in progress), July 2019. 657 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 658 IANA Considerations Section in RFCs", RFC 5226, 659 DOI 10.17487/RFC5226, May 2008, 660 . 662 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 663 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 664 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 665 2009, . 667 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 668 and D. McPherson, "Dissemination of Flow Specification 669 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 670 . 672 Authors' Addresses 674 Huaimo Chen 675 Futurewei 676 Boston, MA 677 USA 679 Email: huaimo.chen@futurewei.com 681 Mehmet Toy 682 Verizon 683 USA 685 Email: mehmet.toy@verizon.com 687 Aijun Wang 688 China Telecom 689 Beiqijia Town, Changping District 690 Beijing, 102209 691 China 693 Email: wangaj3@chinatelecom.cn 695 Zhenqiang Li 696 China Mobile 697 32 Xuanwumen West Ave, Xicheng District 698 Beijing, 100053 699 China 701 Email: lizhengqiang@chinamobile.com 702 Lei Liu 703 Fujitsu 705 USA 707 Email: liulei.kddi@gmail.com 709 Xufeng Liu 710 Volta Networks 712 McLean, VA 713 USA 715 Email: xufeng.liu.ietf@gmail.com