idnits 2.17.1 draft-ppsenak-lsr-igp-event-notification-01.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 exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (March 7, 2022) is 774 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' ** Obsolete normative reference: RFC 3847 (Obsoleted by RFC 5306) == Outdated reference: A later version (-20) exists of draft-ietf-rtgwg-bgp-pic-17 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group P. Psenak, Ed. 3 Internet-Draft L. Ginsberg 4 Intended status: Standards Track Cisco Systems 5 Expires: September 8, 2022 K. Talaulikar 6 Individual Contributor 7 March 7, 2022 9 IS-IS and OSPF Extension for Event Notification 10 draft-ppsenak-lsr-igp-event-notification-01 12 Abstract 14 Link-state protocols like IS-IS and OSPF have been designed to 15 distribute state information - state of the local adjacencies, state 16 of the local prefix reachability, etc. Each state can have 17 additional attributes associated with it, but all the attributes are 18 only meaningful while the state exists. 20 This document extends link-state IGPs to distribute event 21 notifications. An event notification has a very limited lifetime. 22 It is rapidly propagated across the network and leaves no state after 23 its lifetime. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 29 "OPTIONAL" in this document are to be interpreted as described in BCP 30 14 [RFC2119] [RFC8174] when, and only when, they appear in all 31 capitals, as shown here. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 8, 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Requirements for Pulse Notification . . . . . . . . . . . . . 3 69 3. IS-IS Pulse PDUs . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. IS-IS Flooding Scoped Pulse LSP . . . . . . . . . . . . . 4 71 3.2. IS-IS Flooding Scoped Pulse PSNP . . . . . . . . . . . . 5 72 3.3. Flooding Scope Update Process Operation . . . . . . . . . 7 73 3.3.1. FSP-LSP Generation Procedures . . . . . . . . . . . . 8 74 3.3.2. FSP-LSP Acknowledgement Behavior . . . . . . . . . . 8 75 4. Use Case: Supporting BGP-PIC at scale . . . . . . . . . . . . 8 76 4.1. Use of Summarization . . . . . . . . . . . . . . . . . . 9 77 4.2. Use of Pulse in combination w Summarization . . . . . . . 10 78 4.3. IS-IS Summary Component Reachability Loss Pulse TLV 10 79 5. Handling of the Control Plane Restart and ISSU . . . . . . . 13 80 6. OSPF Pulse Notification . . . . . . . . . . . . . . . . . . . 13 81 7. OSPFv3 Pulse Notification . . . . . . . . . . . . . . . . . . 14 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 8.1. New IS-IS PDU Types . . . . . . . . . . . . . . . . . . . 14 84 8.2. Revised sub-TLV table . . . . . . . . . . . . . . . . . . 14 85 8.3. IS-IS Flooding Scope Pulse LSP Entries TLV . . . . . . . 14 86 8.4. IS-IS Summary Component Reachability Loss Pulse TLV . . . 14 87 9. Security Considerations for ISIS . . . . . . . . . . . . . . 14 88 10. Security Considerations for OSPF . . . . . . . . . . . . . . 15 89 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 92 12.2. Informative References . . . . . . . . . . . . . . . . . 16 93 Appendix A. BGP Pulse Handling . . . . . . . . . . . . . . . . . 16 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 96 1. Introduction 98 Link-state IGP protocols like IS-IS and OSPF are primarily used to 99 distribute routing information between routers belonging to a single 100 Autonomous System (AS) and to calculate the reachability for IPv4 or 101 IPv6 prefixes advertised by the individual nodes inside the AS. Each 102 node advertises the state of its local adjacencies, connected 103 prefixes, capabilities, etc. The collection of these states from all 104 the routers inside the area form a link-state database (LSDB) that 105 describes the topology of the area and holds additional state 106 information about the prefixes, router capabilities, etc. 108 Link-state protocols have been designed to distribute state 109 information. More precisely, it's only the existent or steady state 110 that is being advertised - local adjacencies in UP sate, local 111 prefixes that are reachable, etc. When the state does not exist 112 anymore (e.g., adjacency transition to DOWN state), it is simply 113 removed by the advertising node. Each state can have additional 114 attributes associated with it, but all the attributes are only 115 meaningful while the state exists. 117 There are certain types of events, that do not represent a steady 118 state and therefore cannot be advertised, that may be useful for the 119 network operation. 121 This document introduces the capability in link-state protocols to 122 propagate event notifications that have a short and limited lifetime 123 and do not introduce a state into IS-IS, OSPFv2, and OSPFv3. These 124 event notifications are referred to as pulses to reflect their short- 125 lived nature. Pulses may be used to advertise many types of events 126 including those that are positive or negative in nature and for which 127 there is no associated state that is to be maintained by link-state 128 protocols. 130 2. Requirements for Pulse Notification 132 This section describes the basic requirements of the pulse based 133 notification for link-state protocols. 135 Pulse Processing - processing of the pulse on the router is 136 OPTIONAL. It's the decision of the receiver of the pulse whether 137 the pulse is processed and any action is taken. 139 Reliability - the distribution of the pulses MUST be reliable. 141 Separation from Link-State - receiving pulses MUST NOT result in 142 any update of the link-state topology or in any route calculation. 144 Pulse advertisements MUST NOT be sent using existing protocol 145 link-state messages. 147 Limited Lifetime - pulses are short-lived. There is no flushing 148 or purging mechanism for pulses. They MUST be destroyed after 149 their flooding procedure is complete. 151 Limited Retransmissions - pulses MUST be retransmitted, as 152 required by the flooding procedure, only for a limited period. 154 Not Part of Database Sync - pulses MUST NOT be exchanged as part 155 of the initial or post Graceful Restart database synchronization 156 between adjacent peers. 158 Relevance to routing protocol - use of pulses is restricted to 159 information known to the routing protocol as part of its normal 160 operation 162 3. IS-IS Pulse PDUs 164 Two new IS-IS PDUs are introduced for pulse propagation: 166 Flooding Scoped Pulse LSP (FSP-LSP) 168 Flooding Scoped Pulse PSNP (FSP-PSNP) 170 3.1. IS-IS Flooding Scoped Pulse LSP 172 The format of an IS-IS Flooding Scoped Pulse LSP (FSP-LSP) is similar 173 to the format of the Flooding Scoped LSP defined in [RFC7356], with 174 the following fields being removed: 176 "Reserved" 178 "Remaining Lifetime" 180 "Reserved|LSPDBOL|IS Type" 182 FSP-LSP supports all flooding scopes defined in [RFC7356]. 184 An FS-Pulse-LSP has the following format: 186 No. of octets 187 +-------------------------+ 188 | Intradomain Routeing | 1 189 | Protocol Discriminator | 190 +-------------------------+ 191 | Length Indicator | 1 192 +-------------------------+ 193 | Version/Protocol ID | 1 194 | Extension | 195 +-------------------------+ 196 | ID Length | 1 197 +-------------------------+ 198 |R|R|R| PDU Type | 1 199 +-------------------------+ 200 | Version | 1 201 +-------------------------+ 202 |P| Scope | 1 203 +-------------------------+ 204 | PDU Length | 2 205 +-------------------------+ 206 | FSP-LSP ID | ID Length + 2 207 +-------------------------+ 208 | Sequence Number | 4 209 +-------------------------+ 210 | Checksum | 2 211 +-------------------------+ 212 : Variable Length Fields : Variable 213 +-------------------------+ 215 PDU Type: 7 - (suggested - to be assigned by IANA) 217 All fields as defined in [RFC7356] for FS-LSPs 219 3.2. IS-IS Flooding Scoped Pulse PSNP 221 The format of an IS-IS Flooding Scoped Pulse PSNP (FSP-PSNP) is 222 similar to the format of the Flooding Scoped PSNP defined in 223 [RFC7356] 225 FSP-PSNP supports all flooding scopes defined in [RFC7356]. 227 An FSP-PSNP has the following format: 229 No. of octets 230 +-------------------------+ 231 | Intradomain Routeing | 1 232 | Protocol Discriminator | 233 +-------------------------+ 234 | Length Indicator | 1 235 +-------------------------+ 236 | Version/Protocol ID | 1 237 | Extension | 238 +-------------------------+ 239 | ID Length | 1 240 +-------------------------+ 241 |R|R|R| PDU Type | 1 242 +-------------------------+ 243 | Version | 1 244 +-------------------------+ 245 | Reserved | 1 246 +-------------------------+ 247 |U| Scope | 1 248 +-------------------------+ 249 | PDU Length | 2 250 +-------------------------+ 251 | Source ID | ID Length + 1 252 +-------------------------+ 253 : Variable Length Fields : Variable 254 +-------------------------+ 256 PDU Type: 8 (Suggested - to be assigned by IANA) defined in 257 [ISO10589]. 259 All fields of the FSP-PSNP match the definition from Flooding 260 Scoped PSNP in [RFC7356]. 262 Variable-length fields - list of TLVs. 264 This document defines a new TLV to be included in FSP-PSNPs: Flooding 265 Scope Pulse LSP Entries TLV (FSP-LSP Entries TLV) that has the 266 following format: 268 No. of octets 269 +-------------------------+ 270 | Type | 1 271 +-------------------------+ 272 | Length | 1 273 +-------------------------+ 274 | FSP-LSP ID | ID Length + 2 275 +-------------------------+ 276 | Sequence Number | 4 277 +-------------------------+ 278 | Checksum | 2 279 +-------------------------+ 280 : : 281 +-------------------------+ 282 | FSP-LSP ID | ID Length + 2 283 +-------------------------+ 284 | Sequence Number | 4 285 +-------------------------+ 286 | Checksum | 2 287 +-------------------------+ 289 Type: 29 (Suggested - to be assigned by IANA) 291 Length: (ID Length + 8) * number of entries 293 FSP-LSP ID: The ID of the FSP-LSP being acknowledged 295 Sequence Number: Sequence number of the FSP-LSP being acknowledged 297 Checksum: Checksum reported in the FSP-LSP 299 3.3. Flooding Scope Update Process Operation 301 The Update Process in [ISO10589] is responsible for reliable flooding 302 of LSPs. In the case of FSP-LSPs, the lack of persistence introduces 303 some changes in how the Update Process operates. 305 Analagous to what is defined in [RFC7356], there is a separate 306 instance of the Update Process for each scope supported for FSP-LSPs. 307 The circuit(s) on which FSP-LSPs are flooded is limited to those 308 circuits that are participating in the given scope. Consistent 309 support of a given flooding scope on a circuit by all routers 310 operating on that circuit is required. 312 FSP-LSPs are not meant to be retained beyond the minimum time needed 313 to process the information and to provide a reasonable opportunity 314 for flooding the information to neighbors. FSP-LSPs are also not 315 synchronized on adjacency establishment and/or Graceful Restart 316 [RFC8706]. For this reason, an FSP Complete Sequence Number PDU is 317 NOT REQUIRED. Flooding of an FSP-LSP on a circuit ceases after a 318 configurable number of retries. Default number of retries is 319 RECOMMENDED to be 3. 321 Receipt of an FSP-PSNP with a matching Flooding Scope Pulse LSP Entry 322 serves as an acknowledgment of receipt of an FSP-LSP on that circuit. 324 FSP-LSPs SHOULD be retained in the FSP Scope Specific LSDB for 325 ZeroAgeLifetime (60 seconds). This is done to support reliable 326 flooding of the FSP-LSP and to minimize the possibility of 327 reprocessing a previously received FSP-LSP. 329 3.3.1. FSP-LSP Generation Procedures 331 Although sequence numbers in FSP-LSPs are less important than in 332 traditional LSPs since FSP-LSPs are not retained for a significant 333 period and are not purged, they are still useful to identity a newer 334 version of a given FSP-LSP. Nodes which originate FSP-LSPs MUST 335 remember the last sequence number used for a given FSP-LSP and 336 increment the sequence number when generating a new version. 338 FSP-LSP generation SHOULD utilize the "next" FSP-LSP ID each time new 339 pulse information needs to be advertised i.e., if the most recent 340 FSP-LSP ID used was A-00.n, the next set of pulse information SHOULD 341 be advertised using FSP-LSP.ID A-00.n+1. This minimizes the 342 possibility of confusion if other routers in the network have not yet 343 removed A-00.n from their LSPDB. 345 3.3.2. FSP-LSP Acknowledgement Behavior 347 Determining whether a received FSP-LSP is newer than a previously 348 received copy follows the rules defined for LSPs defined in 349 [ISO10589]. 351 Received FSP-LSPs which are either newer or the same as an existing 352 entry in the LSPDB are acknowledged using FSP-PSNPs. 354 Received FSP-LSPs which are older than existing entries in the LSPDB 355 are ignored. The sender of the FSP-LSP will in any case cease 356 flooding such an FSP-LSP after a modest number of retries. 358 4. Use Case: Supporting BGP-PIC at scale 360 In this section we present one practical use case of event based 361 notification in link-state routing protocols. 363 The growth of networks running a link-state routing protocol results 364 in the addition of more state that presents itself in the form of 365 scalability and convergence challenges. The organization of networks 366 into levels/areas and IGP domains helps limit the scope of link-state 367 information within certain boundaries. However, the state related to 368 prefix reachability often requires propagation across a multi-area/ 369 level and/or multi-domain IGP network. 371 Techniques such as summarization have been used traditionally to 372 address the scale challenges associated with advertising prefix state 373 outside of local area/domain. 375 However, this results in suppression of the individual prefix state 376 that is useful for triggering fast-convergence mechanisms outside of 377 the IGPs - e.g., BGP PIC Edge [I-D.ietf-rtgwg-bgp-pic]. 379 In such a scenario, it is desirable to enable the notification of 380 events, such as an individual prefix becoming unreachable, outside of 381 the local area/domain and across the network in a manner that does 382 not leave behind any persistent state in the link-state database. 384 4.1. Use of Summarization 386 Deployment of large networks may utilize a significant number of 387 discrete IGP areas. Advertisement of inter-area prefixes is limited 388 to summaries to reduce the number of prefix advertisements which need 389 to be flooded domain-wide. 391 Considere a network consisting of 100 areas with 1K prefixes/area. 392 In the absence of summarization, there are 100 K prefixes which would 393 be advertised domain-wide. If in each area there are two Area Border 394 Routers (ABRs) - for redundancy purposes - each of which is 395 advertising 1K intra-area prefixes into other areas, there would then 396 be 100*2*1K = 200K prefix advertisements sent domain-wide. 398 If a single summary address is used to represent reachability for the 399 1K prefixes within an area, the number of prefix advertisements 400 flooded domain-wide becomes 100*2*1 = 200 summary prefix 401 adverytisements. 403 The use of summarization dramatically reduces the scale of network- 404 wide flooding, but it also means that a change in reachability to any 405 specific destination covered by a summary is not known to routers 406 outside a given area. 408 4.2. Use of Pulse in combination w Summarization 410 Pulse can be used to signal loss of reachability to an individual 411 destination covered by a summary. In the event that a single node 412 becomes unreachable, this would result in the flooding of 2 pulses 413 (one by each ABR in the impacted area. If we generalize this to loss 414 of reachability to N nodes throughout the network, the total number 415 of additional advertisements is 2N. The received pulses can then be 416 used to trigger BGP-PIC fast convergence. 418 The economy provided by the use of pulses in this use case diminishes 419 linearly with the number of nodes which fail within a given time 420 interval. In the event of a catastrophic network failure where many 421 nodes fail within a given pulse interval, the number of pulses 422 present in the network could begin to approach the number of 423 individual prefixes present in the domain - which would effectively 424 eliminate the scale benefits of the summary. Therefore, when using 425 pulse for this use case, implementations SHOULD limit the number of 426 pulses which are advertised in a given time interval. 428 4.3. IS-IS Summary Component Reachability Loss Pulse TLV 430 IS-IS Summary Component Reachability Loss Pulse (SCRLP) TLV MAY be 431 sent in an FSP-LSP. It is used by the IS-IS L1/L2 routers or by IS- 432 IS Autonomous Boundary Routers (ASBR) that are performing prefix 433 summarization at the area or domain boundary, to inform other nodes 434 in the attached area(s) or domain(s) about the loss of the 435 reachability to a previously reachable component of the summary- 436 prefix inside the area or domain from which the summary-prefix is 437 originated. 439 The IS-IS SCRLP TLV has the following format: 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Type | Length | Flags | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 |R|R|R|R| MT ID | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 |S|Summ-Pfx Len | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Summary Prefix (variable) ... 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Sub-TLV-len | Sub-TLVs (variable) . . . 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 |S| Comp-Pfx Len| 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Component Prefix (variable) ... 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Sub-TLV-len | Sub-TLVs (variable) . . . 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 |S| Comp-Pfx Len| 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Component Prefix (variable) ... 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Sub-TLV-len | Sub-TLVs (variable) . . . 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | ... | 468 where: 470 Type: 1 472 Length: variable 474 Flags: 1 octet. The following flags are defined: 476 0 477 0 1 2 3 4 5 6 7 478 +-+-+-+-+-+-+-+-+ 479 |D|F| Reserved | 480 +-+-+-+-+-+-+-+-+ 482 D-flag: Same as described in section 4.1. of [RFC5305]. 484 F-flag: If unset, then the Summary Prefix and Component 485 Prefix(es) are IPv4 prefixes. If set, then the Summary Prefix 486 and Component Prefix(es) are IPv6 prefixes. 488 The remaining bits are reserved for future use. They MUST be 489 set to zero on transmission and MUST be ignored on receipt. 491 R bits: reserved for future use. They MUST be set to zero on 492 transmission and MUST be ignored on receipt. 494 MT ID: Multitopology Identifier as defined in [RFC5120]. Note 495 that the value 0 is legal. 497 Summ-Pfx Length + Flag: 1 octet 499 Summ-Pfx Length: Length of the Summary Prefix in bits. Valid 500 values are (0-31) when F-flag is unset, (0-127) when F-flag is 501 set. 503 S-bit: MUST be set when Sub-TLVs are present for Summary 504 Prefix, otherwise MUST NOT be set. 506 Summary Prefix: variable. IPv4 or IPv6 Summary Prefix. 508 Sub-TLV-length: 1 octet. Number of octets used by Summary Prefix 509 Sub-TLVs. Only present when S-bit is set. 511 Optional Sub-TLVs: No Sub-TLVs are defined by this document. 513 Comp-Pfx Length + Flag: 1 octet 515 Comp-Pfx Len.: 1 octet. Length of the Component Prefix in 516 bits. Valid values are (1-32) when F-flag is unset, (1-128) 517 when F-flag is set. Comp-Pfx Len MUST be > Summ-Pfx Length. 519 S-bit: MUST be set when Sub-TLVs are present for Component 520 Prefix, otherwise MUST NOT be set. 522 Component Prefix: variable. IPv4 or IPv6 Component Prefix. 524 Sub-TLV-length: 1 octet. Number of octets used by Component 525 Prefix sub-TLVs. Only present when S-bit is set. 527 Optional sub-TLVs: No Sub-TLVs are defined by this document. 529 When an IS-IS L1/L2 router or an IS-IS Autonomous Boundary Router 530 (ASBR) is performing prefix summarization and it loses the 531 reachability to one or more previously reachable component(s) of the 532 summary-prefix inside the area or domain for which the summarization 533 is done, it MAY originate the SCRLP TLV to inform routers in other 534 areas or domains about such summary component-prefix reachability 535 loss. 537 An originator of the SCRLP TLV chooses to advertise it in FSP-LSP 538 with L1 flooding scope and/or FSP-LSP with L2 flooding scope. 540 The IS-IS SCRLP TLV MAY be leaked between levels on L1/L2 router, 541 subject to local policy of such L1/L2 router. 543 IS-IS SCRLP TLV MUST NOT be leaked inside the area if the summary 544 prefix carried in IS-IS SCRLP TLV (Summary Prefix, Summ-Pfx Length) 545 is advertised from such area by L1/L2 router. 547 When the router receives the SCRLP TLV it MAY choose to inform the 548 BGP component on the router. BGP component on the router MAY trigger 549 BGP Prefix Independent Convergence (PIC) as specified in 550 [I-D.ietf-rtgwg-bgp-pic] as a result of such notification. 552 The mechanism on how the IS-IS passes the information from IS-IS 553 SCRLP TLV to the BGP component or how the BGP component uses this 554 information to trigger the PIC is implementation-specific and outside 555 of the scope of this specification. 557 The IS-IS SCRLP TLV may be used by other applications on the 558 receiving node that wish to be notified about the loss of summary 559 component-prefix reachability. The details of such usage are outside 560 of the scope of this specification. 562 5. Handling of the Control Plane Restart and ISSU 564 An egress PE may undergo a control-plane or protocol restart, or and 565 In-Service Software Upgrade. If these events are performed using 566 Nonstop Forwarding (NSF) as specified in [RFC3847] or Nonstop Routing 567 (NSR) procedures, the egress PE reachability inside its area is 568 preserved and no Pulse would be generated as a result of these 569 events. 571 If the IS-IS protocol restart, or route-processor fail-over on the 572 egress PE is performed using cold-restart procedures, the egress PE 573 reachability will be lost and Pulse will be generated by the ABRs 574 connected to the area. This is an expected behavior, as in case of 575 the cold-restart recovery the traffic is expected to be dropped if 576 forwarded to the egress PE and using an alternate BGP path is 577 desirable. 579 6. OSPF Pulse Notification 581 TBD. 583 7. OSPFv3 Pulse Notification 585 TBD. 587 8. IANA Considerations 589 8.1. New IS-IS PDU Types 591 This document includes the definition of two new PDU types that are 592 reflected in the "IS-IS PDU Registry": 594 Value Description 595 ---- --------------------- 596 7 FSP-LSP 597 8 FSP-PSNP 599 8.2. Revised sub-TLV table 601 IANA is requested to modify the table in "TLV Codepoints Registry" by 602 adding columns for FSP-LSP and FSP-PSNP and set FSP-LSP:n and FSP- 603 PSNP:n for all existing TLVs with the exception of 10 604 (Authentication) and 11 (ESN). 606 8.3. IS-IS Flooding Scope Pulse LSP Entries TLV 608 This document makes the following registrations in the IS-IS TLV 609 Codepoints registry: 611 Type Description IIH LSP SNP Purge FSP-LSP FSP-PSNP 612 ---- --------------------- --- --- --- ----- ------- ------- 613 29 FS-LSP Entries TLV n n n n n y 615 8.4. IS-IS Summary Component Reachability Loss Pulse TLV 617 This document makes the following registrations in the IS-IS TLV 618 Codepoints registry: 620 Type Description IIH LSP SNP Purge FSP-LSP FSP-PSNP 621 ---- --------------------- --- --- --- ----- ------- -------- 622 30 Summary Component 623 Reachability Loss 624 Pulse n n n n y n 626 9. Security Considerations for ISIS 628 The introduction of new PDU types introduces the possibility that an 629 attacker could inject a false but apparently valid PDU. The use of 630 cryptographic authentication as defined in [RFC5304] or [RFC5310] 631 minimizes the possibility of such occurrences. 633 Replay attacks could still be possible. Prevention of replay attacks 634 can be done by including the Extended Sequence Numbers(ESN) TLV 635 [RFC7602] in FSP-LSPs and FSP-PSNPs. Note, however, that the use of 636 ESN MUST be done independently for each FSP-LSP ID. It is not safe 637 to use a single ESN for the FSP-LSP PDU Type (as is done with hellos 638 and SNPs) since we cannot guarantee the order in which multiple FSP- 639 LSPs from the same source may arrive at a given node. 641 If a false PDU were to be injected, invalid SCRLP information could 642 falsely trigger BGP-PIC behavior. 644 10. Security Considerations for OSPF 646 TBD. 648 11. Contributors 650 TBD 652 12. References 654 12.1. Normative References 656 [ISO10589] 657 International Organization for Standardization, 658 "Intermediate system to Intermediate system intra-domain 659 routeing information exchange protocol for use in 660 conjunction with the protocol for providing the 661 connectionless-mode Network Service (ISO 8473)", Nov 2002. 663 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 664 Requirement Levels", BCP 14, RFC 2119, 665 DOI 10.17487/RFC2119, March 1997, 666 . 668 [RFC3847] Shand, M. and L. Ginsberg, "Restart Signaling for 669 Intermediate System to Intermediate System (IS-IS)", 670 RFC 3847, DOI 10.17487/RFC3847, July 2004, 671 . 673 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 674 Topology (MT) Routing in Intermediate System to 675 Intermediate Systems (IS-ISs)", RFC 5120, 676 DOI 10.17487/RFC5120, February 2008, 677 . 679 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 680 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 681 2008, . 683 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 684 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 685 2008, . 687 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 688 and M. Fanto, "IS-IS Generic Cryptographic 689 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 690 2009, . 692 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 693 Scope Link State PDUs (LSPs)", RFC 7356, 694 DOI 10.17487/RFC7356, September 2014, 695 . 697 [RFC7602] Chunduri, U., Lu, W., Tian, A., and N. Shen, "IS-IS 698 Extended Sequence Number TLV", RFC 7602, 699 DOI 10.17487/RFC7602, July 2015, 700 . 702 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 703 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 704 May 2017, . 706 [RFC8706] Ginsberg, L. and P. Wells, "Restart Signaling for IS-IS", 707 RFC 8706, DOI 10.17487/RFC8706, February 2020, 708 . 710 12.2. Informative References 712 [I-D.ietf-rtgwg-bgp-pic] 713 Bashandy, A., Filsfils, C., and P. Mohapatra, "BGP Prefix 714 Independent Convergence", draft-ietf-rtgwg-bgp-pic-17 715 (work in progress), October 2021. 717 Appendix A. BGP Pulse Handling 719 Handling of the Pulse by the receiving application is out of scope of 720 this document. This section provides some informational, high-level 721 description on how a BGP on an ingress PE (Provider Edge) device may 722 use the Pulse to trigger the BGP PIC (Prefix Independent 723 Convergence). Note that PIC is a local behavior on ingress PE, which 724 is implementation specific and nothing in this section mandates the 725 implementation to follow what is described here to any degree. 727 Assuming the BGP multi-path destination prefix on an ingress PE, the 728 arrival of the Pulse, that indicates the loss of reachability of the 729 BGP next-hop for the primary path, can trigger the BGP PIC for such 730 prefix. This is similar in nature to what happens on ingress PE 731 without the use of summarization when the BGP next-hop for primary 732 path becomes unreachable. 734 In case the egress PE associated with the primary BGP path went down, 735 BGP on the ingress PE would eventually receive a withdrawal of such 736 path and would re-converge to the alternate path out of multi-paths. 737 Note that this happens independently of and after the BGP PIC was 738 triggered previously. 740 If the loss of reachability signaled by the Pulse is short-lived, it 741 is desirable that BGP reconverge to the state prior to receipt of the 742 Pulse. However, determination of the transient nature of the loss of 743 reachability depends on the absence of BGP updates which would be 744 expected following the loss of reachability to the egress PE. This 745 can be determined by triggering a timer on receipt of the Pulse. If 746 that timer expires without receipt of the expected BGP updates, then 747 BGP can reconverge to the pre-pulse state. The timer duration needs 748 to be long enough to allow for the expected BGP convergence to take 749 place in the case where the loss of reachability to the egress PE is 750 not transient. 752 Authors' Addresses 754 Peter Psenak (editor) 755 Cisco Systems 756 Pribinova Street 10 757 Bratislava 81109 758 Slovakia 760 Email: ppsenak@cisco.com 762 Les Ginsberg 763 Cisco Systems 764 821 Alder Drive 765 Milpitas, CA 95035 766 USA 768 Email: ginsberg@cisco.com 769 Ketan Talaulikar 770 Individual Contributor 772 Email: ketant.ietf@gmail.com