idnits 2.17.1 draft-chen-idr-sr-ingress-protection-06.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 (18 April 2022) is 740 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 156, but not defined == Missing Reference: 'CE2' is mentioned on line 156, but not defined == Unused Reference: 'RFC7356' is defined on line 617, 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 638, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 662, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 675, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-17 ** Downref: Normative reference to an Experimental RFC: RFC 8424 == Outdated reference: A later version (-24) exists of draft-hu-spring-segment-routing-proxy-forwarding-19 -- 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 (~~), 11 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: 20 October 2022 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 18 April 2022 16 SR Path Ingress Protection 17 draft-chen-idr-sr-ingress-protection-06 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 20 October 2022. 48 Copyright Notice 50 Copyright (c) 2022 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 (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. SR Path Ingress Protection Example . . . . . . . . . . . . . 4 67 4. Behavior after Ingress Failure . . . . . . . . . . . . . . . 4 68 5. Extensions to BGP . . . . . . . . . . . . . . . . . . . . . . 5 69 5.1. SR Path Ingress Protection Sub-TLV . . . . . . . . . . . 5 70 5.1.1. Primary Ingress Sub-TLV . . . . . . . . . . . . . . . 6 71 5.1.2. Service Sub-TLV . . . . . . . . . . . . . . . . . . . 7 72 5.1.3. Traffic Description Sub-TLVs . . . . . . . . . . . . 8 73 6. Backup Ingress Behavior . . . . . . . . . . . . . . . . . . . 11 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 9.1. BGP Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . 13 78 9.2. Ingress Protection Information Sub-TLVs . . . . . . . . . 13 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 81 10.2. Informative References . . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 The fast protection of a transit node of a Segment Routing (SR) path 87 or tunnel is described in [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 88 and [I-D.hu-spring-segment-routing-proxy-forwarding]. [RFC8424] 89 presents extensions to RSVP-TE for the fast protection of the ingress 90 node of a traffic engineering (TE) Label Switching Path (LSP). 91 However, these documents do not discuss any protocol extensions for 92 the fast protection of the ingress node of an SR path or tunnel. 94 This document fills that void and specifies protocol extensions to 95 Border Gateway Protocol (BGP) for the fast protection of the ingress 96 node of an SR path or tunnel. Ingress node and ingress, fast 97 protection and protection as well as SR path and SR tunnel will be 98 used exchangeably in the following sections. 100 2. Terminologies 102 The following terminologies are used in this document. 104 SR: Segment Routing 106 SRv6: SR for IPv6 108 SRH: Segment Routing Header 110 SID: Segment Identifier 112 CE: Customer Edge 114 PE: Provider Edge 116 LFA: Loop-Free Alternate 118 TI-LFA: Topology Independent LFA 120 TE: Traffic Engineering 122 BFD: Bidirectional Forwarding Detection 124 VPN: Virtual Private Network 126 L3VPN: Layer 3 VPN 128 FIB: Forwarding Information Base 130 PLR: Point of Local Repair 132 BGP: Border Gateway Protocol 134 IGP: Interior Gateway Protocol 136 OSPF: Open Shortest Path First 138 IS-IS: Intermediate System to Intermediate System 140 3. SR Path Ingress Protection Example 142 To protect against the failure of the (primary) ingress node of a 143 (primary) SR path, a backup ingress node is configured or selected 144 and is different from the (primary) ingress node. A backup SR path 145 from the backup ingress node is computed and installed. Primary 146 ingress and ingress as well as primary SR path and SR path will be 147 used exchangeably. 149 Figure 1 shows an example of protecting ingress PE1 of a SR path, 150 which is from ingress PE1 to egress PE3. 152 ******* ******* 153 [PE1]-----[P1]-----[PE3] PE1 Ingress 154 / | |& &&&&& | \ PEx Provider Edge 155 / | |& | \ CEx Customer Edge 156 [CE1] | |& | [CE2] Px Non Provider Edge 157 \ | |& | / *** SR Path 158 \ | &&&&&& |& | / &&& Backup Path 159 [PE2]-----[P2]-----[PE4] 161 Figure 1: Protecting Ingress PE1 of SR Path PE1-P1-PE3 163 In normal operations, CE1 sends the traffic with destination PE3 to 164 ingress PE1, which imports the traffic into the SR path. 166 When CE1 detects the failure of ingress PE1, it switches the traffic 167 to backup ingress PE2, which imports the traffic from CE1 into a 168 backup SR path. The backup path is from the backup ingress PE2 to 169 the egress PE3. When the traffic is imported into the backup path, 170 it is sent to the egress PE3 along the path. 172 4. Behavior after Ingress Failure 174 After the failure of the ingress of an SR path happens, there are a 175 couple of different ways to detect the failure. In each way, there 176 may be some specific behavior for the traffic source (e.g., CE1) and 177 the backup ingress (e.g., PE2). 179 In one way, the traffic source (e.g., CE1) is responsible for fast 180 detecting the failure of the ingress (e.g., PE1) of an SR path. Fast 181 detecting the failure means detecting the failure in a few or tens of 182 milliseconds. The backup ingress (e.g., PE2) is ready to import the 183 traffic from the traffic source into the backup SR path installed. 185 In normal operations, the source sends the traffic to the ingress of 186 the SR path. When the source detects the failure of the ingress, it 187 switches the traffic to the backup ingress, which delivers the 188 traffic to the egress of the SR path via the backup SR path. 190 In another way, the backup ingress is responsible for fast detecting 191 the failure of the ingress of an SR path. 193 In normal operations, the source (e.g., CE1) sends the traffic to the 194 ingress (e.g., PE1) and may send the traffic to the backup ingress 195 (e.g., PE2). It sends the traffic to the backup ingress (e.g., PE2) 196 after the ingress fails. 198 The backup ingress does not import any traffic from the source into 199 the backup SR path in normal operations. When it detects the failure 200 of the ingress, it imports the traffic from the source into the 201 backup SR path. 203 5. Extensions to BGP 205 For a SR path from a primary ingress node to an egress node, a backup 206 ingress node is selected to protect the failure of the primary 207 ingress node of the SR path. This section describes the extensions 208 to BGP for representing the information for protecting the primary 209 ingress node in a BGP UPDATE message and distributing the information 210 to the backup ingress node. The information includes a SR backup 211 path. 213 [I-D.ietf-idr-segment-routing-te-policy] specifies a way of 214 representing a SR path in a BGP UPDATE message and distributing the 215 SR path to the ingress node of the SR path. 217 This is extended to represent the information for protecting the 218 primary ingress by defining a few of new Sub-TLVs. 220 5.1. SR Path Ingress Protection Sub-TLV 222 A new Sub-TLV, called SR Path Ingress Protection Sub-TLV, is defined. 223 When a UPDATE message is sent to the backup ingress node for 224 protecting the primary ingress node of a SR path, the message 225 contains this Sub-TLV. Its format is illustrated below. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Type (TBD1) | Length (variable) | Flags |A| 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 ~ ~ 233 ~ Sub-TLVs (optional) ~ 234 ~ ~ 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 2: SR Path Ingress Protection Sub-TLV 239 Type: TBD1 is to be assigned by IANA. 241 Length: Variable. 243 Flags: 1 octet. One flag is defined. 245 Flag A: 1 bit. It is set to 247 1: request a backup ingress to let the forwarding entry for 248 the backup SR path be Active. 250 0: request a backup ingress to let the forwarding entry for 251 the backup SR path be inactive initially and to make the 252 entry be active after detecting the failure of the primary 253 ingress node of the primary SR path. 255 A few optional Sub-TLVs are defined, which are Primary Ingress Sub- 256 TLV, Service Sub-TLV and Traffic Description Sub-TLV. 258 5.1.1. Primary Ingress Sub-TLV 260 A Primary Ingress Sub-TLV indicates the IP address of the primary 261 ingress node of a primary SR path. It has two formats: one for 262 primary ingress node IPv4 address and the other for primary ingress 263 node IPv6 address, which are illustrated below. 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Type (1) | Length (4) | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Primary Ingress IPv4 Address (4 octets) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Figure 3: Primary Ingress IPv4 Address Sub-TLV 275 Type: Its value (1 suggested) is to be assigned by IANA. 277 Length: 4. 279 Primary Ingress IPv4 Address: 4 octets. It represents an IPv4 host 280 address of the primary ingress node of a primary SR path. 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Type (2) | Length (16) | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Primary Ingress IPv6 Address (16 octets) | 288 ~ ~ 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Figure 4: Primary Ingress IPv6 Address Sub-TLV 293 Type: Its value (2 suggested) is to be assigned by IANA. 295 Length: 16. 297 Primary Ingress IPv6 Address: 16 octets. It represents an IPv6 host 298 address of the primary ingress node of a primary SR path. 300 5.1.2. Service Sub-TLV 302 A Service Sub-TLV contains a service ID or label to be added into a 303 packet to be carried by a SR path. It has three formats: the first 304 one for the service identified by a label, the second one for the 305 service identified by a service identifier (ID) of 32 bits, and the 306 third one for the service identified by a service identifier (ID) of 307 128 bits. Their formats are illustrated below. 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type (3) | Length (4) | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | zero | Service Label (20 bits) | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 5: Service Label Sub-TLV 319 Type: Its value (3 suggested) is to be assigned by IANA. 321 Length: 4. 323 Service Label: the least significant 20 bits. It represents a label 324 of 20 bits. 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Type (4) | Length (4) | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Service ID (4 octets) | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Figure 6: 32 Bits Service ID Sub-TLV 336 Type: Its value (4 suggested) is to be assigned by IANA. 338 Length: 4. 340 Service ID: 4 octets. It represents a Service Identifier (ID) of 32 341 bits. 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Type (5) | Length (16) | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Service ID (16 octets) | 349 ~ ~ 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Figure 7: 128 Bits Service ID Sub-TLV 354 Type: Its value (5 suggested) is to be assigned by IANA. 356 Length: 16. 358 Service ID: 16 octets. It represents a Service Identifier (ID) of 359 128 bits. 361 5.1.3. Traffic Description Sub-TLVs 363 A Traffic Description Sub-TLV describes the traffic to be imported 364 into a backup SR path. Five Traffic Description Sub-TLVs are 365 defined. Two of them are FEC Sub-TLVs and the others are interface 366 Sub-TLVs. 368 Two FEC Sub-TLVs are IPv4 and IPv6 FEC Sub-TLVs. Their formats are 369 illustrated below. 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Type (6) |Length(variable| 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 |IPv4 Prefix Len| IPv4 Prefix ~ 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 ~ (Optional) Virtual Network ID (2 octets) ~ 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Figure 8: IPv4 FEC Sub-TLV 383 Type: Its value (6 suggested) is to be assigned by IANA. 385 Length: Variable. 387 IPv4 Prefix Len: Indicates the length of the IPv4 Prefix. 389 IPv4 Prefix: IPv4 Prefix rounded to octets. 391 Virtual Network ID: 2 octets. This is optional. It indicates the 392 ID of a virtual network. 394 0 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Type (7) |Length(variable| 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 |IPv6 Prefix Len| IPv6 Prefix ~ 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 ~ Optional Virtual Network ID (2 octets) ~ 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Figure 9: IPv6 FEC Sub-TLV 406 Type: Its value (7 suggested) is to be assigned by IANA. 408 Length: Variable. 410 IPv6 Prefix Len: Indicates the length of the IPv6 Prefix. 412 IPv6 Prefix: IPv6 Prefix rounded to octets. 414 Virtual Network ID: 2 octets. This is optional. It indicates the 415 ID of a virtual network. 417 An Interface sub-TLV indicates the interface from which the traffic 418 is received and imported into the backup SR path/tunnel. It has 419 three formats: one for interface index, the other two for IPv4 and 420 IPv6 address, which are illustrated below. 422 0 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Type (8) | Length (4) | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Interface Index (4 octets) | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 Figure 10: Interface Index Sub-TLV 432 Type: Its value (8 suggested) is to be assigned by IANA. 434 Length: 4. 436 Interface Index: 4 octets. It indicates the index of an interface. 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Type (9) | Length (4) | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Interface IPv4 Address (4 octets) | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Figure 11: Interface IPv4 Address Sub-TLV 448 Type: Its value (9 suggested) is to be assigned by IANA. 450 Length: 4. 452 Interface IPv4 Address: 4 octets. It represents the IPv4 address of 453 an interface. 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Type (10) | Length (16) | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Interface IPv6 Address (16 octets) | 461 ~ ~ 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Figure 12: Interface IPv6 Address Sub-TLV 466 Type: Its value (10 suggested) is to be assigned by IANA. 468 Length: 16. 470 Interface IPv6 Address: 16 octets. It represents the IPv6 address 471 of an interface. 473 6. Backup Ingress Behavior 475 When a backup ingress node receives a UPDATE message containing the 476 information for protecting the primary ingress node of a SR path, it 477 installs a forwarding entry in its FIB based on the information. The 478 information is encoded in a SR policy of the following structure: 480 SR Policy SAFI NLRI: 481 Attributes: 482 Tunnel Encaps Attribute (23) 483 Tunnel Type (15): SR Policy 484 SR Path Ingress Protection Sub-TLV 485 Primary Ingress Sub-TLV 486 Service Sub-TLV 487 Traffic Description Sub-TLV 488 Preference Sub-TLV 489 Binding SID Sub-TLV 490 Explicit NULL Label Policy (ENLP) Sub-TLV 491 Priority Sub-TLV 492 Policy Name Sub-TLV 493 Segment List Sub-TLV 494 Weight Sub-TLV 495 Segment Sub-TLV 496 Segment Sub-TLV 497 ... 498 ... 500 Where: 502 o SR Policy SAFI NLRI is defined in 503 [I-D.ietf-idr-segment-routing-te-policy]. 505 o Tunnel Encapsulation Attribute is defined in 506 [I-D.ietf-idr-tunnel-encaps]. 508 o Tunnel Type of SR Policy is defined in 509 [I-D.ietf-idr-segment-routing-te-policy]. 511 o SR Path Ingress Protection, Primary Ingress, Service and Traffic 512 Description Sub-TLVs are defined in this document. 514 o Preference, Binding SID, ENLP, Priority, Policy Name, Segment 515 List, Weight and Segment Sub-TLVs are defined in 516 [I-D.ietf-idr-segment-routing-te-policy]. 518 After receiving a SR policy with a SR Path Ingress Protection Sub- 519 TLV, the backup ingress node will install one or more candidate paths 520 into its "BGP table". Another module such as SRPM will choose one or 521 more paths and install the forwarding entries for them in the data 522 plane. 524 The forwarding entries for the paths installed in the data plane will 525 be set to be inactive if the flag A in the SR Path Ingress Protection 526 Sub-TLV is zero. When the primary ingress node fails, these 527 forwarding entries are set to be active. The failure of the primary 528 ingress may be detected by the backup ingress node through using a 529 mechanism such as BFD. The IP address of the primary ingress in the 530 Primary Ingress Sub-TLV may be used for detecting the failure of the 531 primary ingress node. 533 If the flag A in the SR Path Ingress Protection Sub-TLV is one, then 534 the forwarding entries for the paths installed in the data plane will 535 be set to be active. 537 When there is a Service Sub-TLV in the SR Path Ingress Protection 538 Sub-TLV, the ID or Label in the Service Sub-TLV will be included in 539 the forwarding entries. When a packet is imported into a backup SR 540 path using the forwarding entries, the service ID or Label is pushed 541 first and then the sequence of segments represented in the Segment 542 List Sub-TLV. 544 7. Security Considerations 546 Protocol extensions defined in this document do not affect the BGP 547 security other than those as discussed in the Security Considerations 548 section of [RFC5575]. 550 8. Acknowledgements 552 The authors of this document would like to thank Dhruv Dhody for the 553 comments. 555 9. IANA Considerations 557 9.1. BGP Tunnel Encapsulation Attribute Sub-TLVs 559 Under Existing Registry Name: "BGP Tunnel Encapsulation Attribute 560 Sub-TLVs", IANA is requested to assign a new Sub-TLV value for SR 561 Path Ingress Protection as follows: 563 Value sub-TLV Name Reference 564 ----- ------------------------------------ -------------- 565 TBD1 SR Path Ingress Protection Sub-TLV This Document 567 9.2. Ingress Protection Information Sub-TLVs 569 A new registry called "Ingress Protection Information Sub-TLVs" is 570 defined in this document. IANA is requested to create and maintain 571 new registry: 573 o Ingress Protection Information Sub-TLVs 575 Initial values for the registry are given below. The future 576 assignments are to be made through IETF Review [RFC5226]. 578 Value sub-TLV Name Reference 579 ----- ------------------------------------- -------------- 580 0 Reserved 581 1 Primary Ingress IPv4 Address Sub-TLV This Document 582 2 Primary Ingress IPv6 Address Sub-TLV This Document 583 3 Service Label Sub-TLV This Document 584 4 32 Bits Service ID Sub-TLV This Document 585 5 128 Bits Service ID Sub-TLV This Document 586 6 IPv4 FEC Sub-TLV This Document 587 7 IPv6 FEC Sub-TLV This Document 588 8 Interface Index Sub-TLV This Document 589 9 Interface IPv4 Address Sub-TLV This Document 590 10 Interface IPv6 Address Sub-TLV This Document 591 11-255 Unassigned 593 10. References 595 10.1. Normative References 597 [I-D.ietf-idr-segment-routing-te-policy] 598 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 599 Jain, D., and S. Lin, "Advertising Segment Routing 600 Policies in BGP", Work in Progress, Internet-Draft, draft- 601 ietf-idr-segment-routing-te-policy-17, 14 April 2022, 602 . 605 [I-D.ietf-idr-tunnel-encaps] 606 Patel, K., Velde, G. V. D., Sangli, S. R., and J. Scudder, 607 "The BGP Tunnel Encapsulation Attribute", Work in 608 Progress, Internet-Draft, draft-ietf-idr-tunnel-encaps-22, 609 7 January 2021, . 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, 614 DOI 10.17487/RFC2119, March 1997, 615 . 617 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 618 Scope Link State PDUs (LSPs)", RFC 7356, 619 DOI 10.17487/RFC7356, September 2014, 620 . 622 [RFC8424] Chen, H., Ed. and R. Torvi, Ed., "Extensions to RSVP-TE 623 for Label Switched Path (LSP) Ingress Fast Reroute (FRR) 624 Protection", RFC 8424, DOI 10.17487/RFC8424, August 2018, 625 . 627 10.2. Informative References 629 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 630 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 631 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 632 "Topology Independent Fast Reroute using Segment Routing", 633 Work in Progress, Internet-Draft, draft-bashandy-rtgwg- 634 segment-routing-ti-lfa-05, 4 October 2018, 635 . 638 [I-D.hegde-spring-node-protection-for-sr-te-paths] 639 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 640 "Node Protection for SR-TE Paths", Work in Progress, 641 Internet-Draft, draft-hegde-spring-node-protection-for-sr- 642 te-paths-07, 30 July 2020, 643 . 646 [I-D.hu-spring-segment-routing-proxy-forwarding] 647 Hu, Z., Chen, H., Yao, J., Bowers, C., Yongqing, and 648 Yisong, "SR-TE Path Midpoint Restoration", Work in 649 Progress, Internet-Draft, draft-hu-spring-segment-routing- 650 proxy-forwarding-19, 11 April 2022, 651 . 654 [I-D.ietf-spring-segment-routing-policy] 655 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 656 P. Mattes, "Segment Routing Policy Architecture", Work in 657 Progress, Internet-Draft, draft-ietf-spring-segment- 658 routing-policy-22, 22 March 2022, 659 . 662 [I-D.sivabalan-pce-binding-label-sid] 663 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 664 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 665 in PCE-based Networks.", Work in Progress, Internet-Draft, 666 draft-sivabalan-pce-binding-label-sid-07, 8 July 2019, 667 . 670 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 671 IANA Considerations Section in RFCs", RFC 5226, 672 DOI 10.17487/RFC5226, May 2008, 673 . 675 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 676 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 677 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 678 2009, . 680 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 681 and D. McPherson, "Dissemination of Flow Specification 682 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 683 . 685 Authors' Addresses 687 Huaimo Chen 688 Futurewei 689 Boston, MA, 690 United States of America 691 Email: huaimo.chen@futurewei.com 692 Mehmet Toy 693 Verizon 694 United States of America 695 Email: mehmet.toy@verizon.com 697 Aijun Wang 698 China Telecom 699 Beiqijia Town, Changping District 700 Beijing 701 102209 702 China 703 Email: wangaj3@chinatelecom.cn 705 Zhenqiang Li 706 China Mobile 707 32 Xuanwumen West Ave, Xicheng District 708 Beijing 709 100053 710 China 711 Email: lizhengqiang@chinamobile.com 713 Lei Liu 714 Fujitsu 715 United States of America 716 Email: liulei.kddi@gmail.com 718 Xufeng Liu 719 Volta Networks 720 McLean, VA 721 United States of America 722 Email: xufeng.liu.ietf@gmail.com