idnits 2.17.1 draft-ppsenak-lsr-igp-event-notification-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 157: '... OPTIONAL. It's the decision of ...' RFC 2119 keyword, line 160: '...bution of the pulses MUST be reliable....' RFC 2119 keyword, line 162: '... - receiving pulses MUST NOT result in...' RFC 2119 keyword, line 164: '...e advertisements MUST NOT be sent usin...' RFC 2119 keyword, line 168: '...or pulses. They MUST be destroyed aft...' (24 more instances...) 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 (July 5, 2021) is 998 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: 'RFC2119' is mentioned on line 31, but not defined == Missing Reference: 'RFC8174' is mentioned on line 31, but not defined == Missing Reference: 'RFC5120' is mentioned on line 437, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' == Outdated reference: A later version (-20) exists of draft-ietf-rtgwg-bgp-pic-13 Summary: 1 error (**), 0 flaws (~~), 5 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 K. Talaulikar 5 Expires: January 6, 2022 Cisco Systems 6 July 5, 2021 8 IS-IS and OSPF Extension for Event Notification 9 draft-ppsenak-lsr-igp-event-notification-00 11 Abstract 13 Link-state protocols like IS-IS and OSPF have been designed to 14 distribute state information - state of the local adjacencies, state 15 of the local prefix reachability, etc. Each state can have 16 additional attributes associated with it, but all the attributes are 17 only meaningful while the state exists. 19 This document extends link-state IGPs to distribute event 20 notifications. An event notification has a very limited lifetime. 21 It is rapidly propagated across the network and leaves no state after 22 its lifetime. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 28 "OPTIONAL" in this document are to be interpreted as described in BCP 29 14 [RFC2119] [RFC8174] when, and only when, they appear in all 30 capitals, as shown here. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 6, 2022. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Requirements for Pulse Notification . . . . . . . . . . . . . 4 69 4. IS-IS Pulse PDUs . . . . . . . . . . . . . . . . . . . . . . 4 70 4.1. IS-IS Flooding Scoped Pulse LSP . . . . . . . . . . . . . 4 71 4.2. IS-IS Flooding Scoped Pulse PSNP . . . . . . . . . . . . 5 72 4.3. Flooding Scope Update Process Operation . . . . . . . . . 7 73 4.3.1. FSP-LSP Generation Procedures . . . . . . . . . . . . 8 74 4.3.2. FSP-LSP Acknowledgement Behavior . . . . . . . . . . 8 75 5. IS-IS Summary Component Reachability Loss Pulse TLV . . 8 76 6. OSPF Pulse Notification . . . . . . . . . . . . . . . . . . . 11 77 7. OSPFv3 Pulse Notification . . . . . . . . . . . . . . . . . . 11 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 8.1. New IS-IS PDU Types . . . . . . . . . . . . . . . . . . . 11 80 8.2. Revised sub-TLV table . . . . . . . . . . . . . . . . . . 12 81 8.3. IS-IS Flooding Scope Pulse LSP Entries TLV . . . . . . . 12 82 8.4. IS-IS Summary Component Reachability Loss Pulse TLV . . . 12 83 9. Security Considerations for ISIS . . . . . . . . . . . . . . 12 84 10. Security Considerations for OSPF . . . . . . . . . . . . . . 13 85 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 88 12.2. Informative References . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 91 1. Introduction 93 Link-state IGP protocols like IS-IS and OSPF are primarily used to 94 distribute routing information between routers belonging to a single 95 Autonomous System (AS) and to calculate the reachability for IPv4 or 96 IPv6 prefixes advertised by the individual nodes inside the AS. Each 97 node advertises the state of its local adjacencies, connected 98 prefixes, capabilities, etc. The collection of these states from all 99 the routers inside the area form a link-state database (LSDB) that 100 describes the topology of the area and holds additional state 101 information about the prefixes, router capabilities, etc. 103 Link-state protocols have been designed to distribute state 104 information. More precisely, it's only the existent or steady state 105 that is being advertised - local adjacencies in UP sate, local 106 prefixes that are reachable, etc. When the state does not exist 107 anymore (e.g., adjacency transition to DOWN state), it is simply 108 removed by the advertising node. Each state can have additional 109 attributes associated with it, but all the attributes are only 110 meaningful while the state exists. 112 There are certain types of events, that do not represent a steady 113 state and therefore cannot be advertised, that may be useful for the 114 network operation. 116 This document introduces the capability in link-state protocols to 117 propagate event notifications that have a short and limited lifetime 118 and do not introduce a state into IS-IS, OSPFv2, and OSPFv3. These 119 event notifications are referred to as pulses to reflect their short- 120 lived nature. Pulses may be used to advertise many types of events 121 including those that are positive or negative in nature and for which 122 there is no associated state that is to be maintained by link-state 123 protocols. 125 2. Use Case 127 In this section we present one practical use case of event based 128 notification in link-state routing protocols. 130 The growth of networks running link-state routing protocol results in 131 the addition of more state that presents itself in the form of 132 scalability and convergence challenges. The organization of networks 133 into levels/areas and IGP domains helps limit the scope of link-state 134 information within certain boundaries. However, the state related to 135 prefix reachability often requires propagation across a multi-area/ 136 level and/or multi-domain IGP network. 138 Techniques such as summarization have been used traditionally to 139 address the scale challenges associated with advertising prefix state 140 outside of local area/domain. 142 However, this results in suppression of the individual prefix state 143 that is useful for triggering fast-convergence mechanisms outside of 144 the IGPs - e.g., BGP PIC Edge [I-D.ietf-rtgwg-bgp-pic]. 146 In such a scenario, it is desirable to enable the notification of 147 events, such as an individual prefix becoming unreachable, outside of 148 the local area/domain and across the network in a manner that does 149 not leave behind any persistent state in the link-state database. 151 3. Requirements for Pulse Notification 153 This section describes the basic requirements of the pulse based 154 notification for link-state protocols. 156 Pulse Processing - processing of the pulse on the router is 157 OPTIONAL. It's the decision of the receiver of the pulse whether 158 the pulse is processed and any action is taken. 160 Reliability - the distribution of the pulses MUST be reliable. 162 Separation from Link-State - receiving pulses MUST NOT result in 163 any update of the link-state topology or in any route calculation. 164 Pulse advertisements MUST NOT be sent using existing protocol 165 link-state messages. 167 Limited Lifetime - pulses are short-lived. There is no flushing 168 or purging mechanism for pulses. They MUST be destroyed after 169 their flooding procedure is complete. 171 Limited Retransmissions - pulses MUST be retransmitted, as 172 required by the flooding procedure, only for a limited period. 174 Not Part of Database Sync - pulses MUST NOT be exchanged as part 175 of the initial or post Graceful Restart database synchronization 176 between adjacent peers. 178 4. IS-IS Pulse PDUs 180 Two new IS-IS PDUs are introduced for pulse propagation: 182 Flooding Scoped Pulse LSP (FSP-LSP) 184 Flooding Scoped Pulse PSNP (FSP-PSNP) 186 4.1. IS-IS Flooding Scoped Pulse LSP 188 The format of an IS-IS Flooding Scoped Pulse LSP (FSP-LSP) is similar 189 to the format of the Flooding Scoped LSP defined in [RFC7356], with 190 the following fields being removed: 192 "Reserved" 193 "Remaining Lifetime" 195 "Reserved|LSPDBOL|IS Type" 197 FSP-LSP supports all flooding scopes defined in [RFC7356]. 199 An FS-Pulse-LSP has the following format: 201 No. of octets 202 +-------------------------+ 203 | Intradomain Routeing | 1 204 | Protocol Discriminator | 205 +-------------------------+ 206 | Length Indicator | 1 207 +-------------------------+ 208 | Version/Protocol ID | 1 209 | Extension | 210 +-------------------------+ 211 | ID Length | 1 212 +-------------------------+ 213 |R|R|R| PDU Type | 1 214 +-------------------------+ 215 | Version | 1 216 +-------------------------+ 217 |P| Scope | 1 218 +-------------------------+ 219 | PDU Length | 2 220 +-------------------------+ 221 | FSP-LSP ID | ID Length + 2 222 +-------------------------+ 223 | Sequence Number | 4 224 +-------------------------+ 225 | Checksum | 2 226 +-------------------------+ 227 : Variable Length Fields : Variable 228 +-------------------------+ 230 PDU Type: 7 - (suggested - to be assigned by IANA) 232 All fields as defined in [RFC7356] for FS-LSPs 234 4.2. IS-IS Flooding Scoped Pulse PSNP 236 The format of an IS-IS Flooding Scoped Pulse PSNP (FSP-PSNP) is 237 similar to the format of the Flooding Scoped PSNP defined in 238 [RFC7356] 239 FSP-PSNP supports all flooding scopes defined in [RFC7356]. 241 An FSP-PSNP has the following format: 243 No. of octets 244 +-------------------------+ 245 | Intradomain Routeing | 1 246 | Protocol Discriminator | 247 +-------------------------+ 248 | Length Indicator | 1 249 +-------------------------+ 250 | Version/Protocol ID | 1 251 | Extension | 252 +-------------------------+ 253 | ID Length | 1 254 +-------------------------+ 255 |R|R|R| PDU Type | 1 256 +-------------------------+ 257 | Version | 1 258 +-------------------------+ 259 | Reserved | 1 260 +-------------------------+ 261 |U| Scope | 1 262 +-------------------------+ 263 | PDU Length | 2 264 +-------------------------+ 265 | Source ID | ID Length + 1 266 +-------------------------+ 267 : Variable Length Fields : Variable 268 +-------------------------+ 270 PDU Type: 8 (Suggested - to be assigned by IANA) defined in 271 [ISO10589]. 273 All fields of the FSP-PSNP match the definition from Flooding 274 Scoped PSNP in [RFC7356]. 276 Variable-length fields - list of TLVs. 278 This document defines a new TLV to be included in FSP-PSNPs: Flooding 279 Scope Pulse LSP Entries TLV (FSP-LSP Entries TLV) that has the 280 following format: 282 No. of octets 283 +-------------------------+ 284 | Type | 1 285 +-------------------------+ 286 | Length | 1 287 +-------------------------+ 288 | FSP-LSP ID | ID Length + 2 289 +-------------------------+ 290 | Sequence Number | 4 291 +-------------------------+ 292 | Checksum | 2 293 +-------------------------+ 294 : : 295 +-------------------------+ 296 | FSP-LSP ID | ID Length + 2 297 +-------------------------+ 298 | Sequence Number | 4 299 +-------------------------+ 300 | Checksum | 2 301 +-------------------------+ 303 Type: 29 (Suggested - to be assigned by IANA) 305 Length: (ID Length + 8) * number of entries 307 FSP-LSP ID: The ID of the FSP-LSP being acknowledged 309 Sequence Number: Sequence number of the FSP-LSP being acknowledged 311 Checksum: Checksum reported in the FSP-LSP 313 4.3. Flooding Scope Update Process Operation 315 The Update Process in [ISO10589] is responsible for reliable flooding 316 of LSPs. In the case of FSP-LSPs, the lack of persistence introduces 317 some changes in how the Update Process operates. 319 Analagous to what is defined in [RFC7356], there is a separate 320 instance of the Update Process for each scope supported for FSP-LSPs. 321 The circuit(s) on which FSP-LSPs are flooded is limited to those 322 circuits that are participating in the given scope. Consistent 323 support of a given flooding scope on a circuit by all routers 324 operating on that circuit is required. 326 FSP-LSPs are not meant to be retained beyond the minimum time needed 327 to process the information and to provide a reasonable opportunity 328 for flooding the information to neighbors. FSP-LSPs are also not 329 synchronized on adjacency establishment and/or Graceful Restart 330 [RFC8706]. For this reason, an FSP Complete Sequence Number PDU is 331 NOT REQUIRED. Flooding of an FSP-LSP on a circuit ceases after a 332 configurable number of retries. Default number of retries is 333 RECOMMENDED to be 3. 335 Receipt of an FSP-PSNP with a matching Flooding Scope Pulse LSP Entry 336 serves as an acknowledgment of receipt of an FSP-LSP on that circuit. 338 FSP-LSPs SHOULD be retained in the FSP Scope Specific LSDB for 339 ZeroAgeLifetime (60 seconds). This is done to support reliable 340 flooding of the FSP-LSP and to minimize the possibility of 341 reprocessing a previously received FSP-LSP. 343 4.3.1. FSP-LSP Generation Procedures 345 Although sequence numbers in FSP-LSPs are less important than in 346 traditional LSPs since FSP-LSPs are not retained for a significant 347 period and are not purged, they are still useful to identity a newer 348 version of a given FSP-LSP. Nodes which originate FSP-LSPs MUST 349 remember the last sequence number used for a given FSP-LSP and 350 increment the sequence number when generating a new version. 352 FSP-LSP generation SHOULD utilize the "next" FSP-LSP ID each time new 353 pulse information needs to be advertised i.e., if the most recent 354 FSP-LSP ID used was A-00.n, the next set of pulse information SHOULD 355 be advertised using FSP-LSP.ID A-00.n+1. This minimizes the 356 possibility of confusion if other routers in the network have not yet 357 removed A-00.n from their LSPDB. 359 4.3.2. FSP-LSP Acknowledgement Behavior 361 Determining whether a received FSP-LSP is newer than a previously 362 received copy follows the rules defined for LSPs defined in 363 [ISO10589]. 365 Received FSP-LSPs which are either newer or the same as an existing 366 entry in the LSPDB are acknowledged using FSP-PSNPs. 368 Received FSP-LSPs which are older than existing entries in the LSPDB 369 are ignored. The sender of the FSP-LSP will in any case cease 370 flooding such an FSP-LSP after a modest number of retries. 372 5. IS-IS Summary Component Reachability Loss Pulse TLV 374 IS-IS Summary Component Reachability Loss Pulse (SCRLP) TLV MAY be 375 sent in an FSP-LSP. It is used by the IS-IS L1/L2 routers or by an 376 IS-IS Autonomous Boundary Router (ASBR) that is performing prefix 377 summarization at the area or domain boundary, to inform other nodes 378 in the attached area(s) or domain(s) about the loss of the 379 reachability to a previously reachable component of the summary- 380 prefix inside the area or domain from which the summary-prefix is 381 originated. 383 The IS-IS SCRLP TLV has the following format: 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Type | Length | Flags | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 |R|R|R|R| MT ID | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 |S|Summ-Pfx Len | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Summary Prefix (variable) ... 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Sub-TLV-len | Sub-TLVs (variable) . . . 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 |S| Comp-Pfx Len| 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Component Prefix (variable) ... 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Sub-TLV-len | Sub-TLVs (variable) . . . 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 |S| Comp-Pfx Len| 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Component Prefix (variable) ... 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Sub-TLV-len | Sub-TLVs (variable) . . . 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | ... | 412 where: 414 Type: 1 416 Length: variable 418 Flags: 1 octet. The following flags are defined: 420 0 421 0 1 2 3 4 5 6 7 422 +-+-+-+-+-+-+-+-+ 423 |D|F| Reserved | 424 +-+-+-+-+-+-+-+-+ 425 D-flag: Same as described in section 4.1. of [RFC5305]. 427 F-flag: If unset, then the Summary Prefix and Component 428 Prefix(es) are IPv4 prefixes. If set, then the Summary Prefix 429 and Component Prefix(es) are IPv6 prefixes. 431 The remaining bits are reserved for future use. They MUST be 432 set to zero on transmission and MUST be ignored on receipt. 434 R bits: reserved for future use. They MUST be set to zero on 435 transmission and MUST be ignored on receipt. 437 MT ID: Multitopology Identifier as defined in [RFC5120]. Note 438 that the value 0 is legal. 440 Summ-Pfx Length + Flag: 1 octet 442 Summ-Pfx Length: Length of the Summary Prefix in bits. Valid 443 values are (0-31) when F-flag is unset, (0-127) when F-flag is 444 set. 446 S-bit: MUST be set when Sub-TLVs are present for Summary 447 Prefix, otherwise MUST NOT be set. 449 Summary Prefix: variable. IPv4 or IPv6 Summary Prefix. 451 Sub-TLV-length: 1 octet. Number of octets used by Summary Prefix 452 Sub-TLVs. Only present when S-bit is set. 454 Optional Sub-TLVs: No Sub-TLVs are defined by this document. 456 Comp-Pfx Length + Flag: 1 octet 458 Comp-Pfx Len.: 1 octet. Length of the Component Prefix in 459 bits. Valid values are (1-32) when F-flag is unset, (1-128) 460 when F-flag is set. Comp-Pfx Len MUST be > Summ-Pfx Length. 462 S-bit: MUST be set when Sub-TLVs are present for Component 463 Prefix, otherwise MUST NOT be set. 465 Component Prefix: variable. IPv4 or IPv6 Component Prefix. 467 Sub-TLV-length: 1 octet. Number of octets used by Component 468 Prefix sub-TLVs. Only present when S-bit is set. 470 Optional sub-TLVs: No Sub-TLVs are defined by this document. 472 When an IS-IS L1/L2 router or an IS-IS Autonomous Boundary Router 473 (ASBR) is performing prefix summarization and it loses the 474 reachability to one or more previously reachable component(s) of the 475 summary-prefix inside the area or domain for which the summarization 476 is done, it MAY originate the SCRLP TLV to inform routers in other 477 areas or domains about such summary component-prefix reachability 478 loss. 480 An originator of the SCRLP TLV chooses to advertise it in FSP-LSP 481 with L1 flooding scope and/or FSP-LSP with L2 flooding scope. 483 The IS-IS SCRLP TLV MAY be leaked between levels on L1/L2 router, 484 subject to local policy of such L1/L2 router. 486 IS-IS SCRLP TLV MUST NOT be leaked inside the area if the summary 487 prefix carried in IS-IS SCRLP TLV (Summary Prefix, Summ-Pfx Length) 488 is advertised from such area by L1/L2 router. 490 When the router receives the SCRLP TLV it MAY choose to inform the 491 BGP component on the router. BGP component on the router MAY trigger 492 BGP Prefix Independent Convergence (PIC) as specified in 493 [I-D.ietf-rtgwg-bgp-pic] as a result of such notification. 495 The mechanism on how the IS-IS passes the information from IS-IS 496 SCRLP TLV to the BGP component or how the BGP component uses this 497 information to trigger the PIC is implementation-specific and outside 498 of the scope of this specification. 500 The IS-IS SCRLP TLV may be used by other applications on the 501 receiving node that wish to be notified about the loss of summary 502 component-prefix reachability. The details of such usage are outside 503 of the scope of this specification. 505 6. OSPF Pulse Notification 507 TBD. 509 7. OSPFv3 Pulse Notification 511 TBD. 513 8. IANA Considerations 515 8.1. New IS-IS PDU Types 517 This document includes the definition of two new PDU types that are 518 reflected in the "IS-IS PDU Registry": 520 Value Description 521 ---- --------------------- 522 7 FSP-LSP 523 8 FSP-PSNP 525 8.2. Revised sub-TLV table 527 IANA is requested to modify the table in "TLV Codepoints Registry" by 528 adding columns for FSP-LSP and FSP-PSNP and set FSP-LSP:n and FSP- 529 PSNP:n for all existing TLVs with the exception of 10 530 (Authentication) and 11 (ESN). 532 8.3. IS-IS Flooding Scope Pulse LSP Entries TLV 534 This document makes the following registrations in the IS-IS TLV 535 Codepoints registry: 537 Type Description IIH LSP SNP Purge FSP-LSP FSP-PSNP 538 ---- --------------------- --- --- --- ----- ------- ------- 539 29 FS-LSP Entries TLV n n n n n y 541 8.4. IS-IS Summary Component Reachability Loss Pulse TLV 543 This document makes the following registrations in the IS-IS TLV 544 Codepoints registry: 546 Type Description IIH LSP SNP Purge FSP-LSP FSP-PSNP 547 ---- --------------------- --- --- --- ----- ------- -------- 548 30 Summary Component 549 Reachability Loss 550 Pulse n n n n y n 552 9. Security Considerations for ISIS 554 The introduction of new PDU types introduces the possibility that an 555 attacker could inject a false but apparently valid PDU. The use of 556 cryptographic authentication as defined in [RFC5304] or [RFC5310] 557 minimizes the possibility of such occurrences. 559 Replay attacks could still be possible. Prevention of replay attacks 560 can be done by including the Extended Sequence Numbers(ESN) TLV 561 [RFC7602] in FSP-LSPs and FSP-PSNPs. Note, however, that the use of 562 ESN MUST be done independently for each FSP-LSP ID. It is not safe 563 to use a single ESN for the FSP-LSP PDU Type (as is done with hellos 564 and SNPs) since we cannot guarantee the order in which multiple FSP- 565 LSPs from the same source may arrive at a given node. 567 If a false PDU were to be injected, invalid SCRLP information could 568 falsely trigger BGP-PIC behavior. 570 10. Security Considerations for OSPF 572 TBD. 574 11. Contributors 576 TBD 578 12. References 580 12.1. Normative References 582 [ISO10589] 583 International Organization for Standardization, 584 "Intermediate system to Intermediate system intra-domain 585 routeing information exchange protocol for use in 586 conjunction with the protocol for providing the 587 connectionless-mode Network Service (ISO 8473)", Nov 2002. 589 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 590 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 591 2008, . 593 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 594 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 595 2008, . 597 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 598 and M. Fanto, "IS-IS Generic Cryptographic 599 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 600 2009, . 602 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 603 Scope Link State PDUs (LSPs)", RFC 7356, 604 DOI 10.17487/RFC7356, September 2014, 605 . 607 [RFC7602] Chunduri, U., Lu, W., Tian, A., and N. Shen, "IS-IS 608 Extended Sequence Number TLV", RFC 7602, 609 DOI 10.17487/RFC7602, July 2015, 610 . 612 [RFC8706] Ginsberg, L. and P. Wells, "Restart Signaling for IS-IS", 613 RFC 8706, DOI 10.17487/RFC8706, February 2020, 614 . 616 12.2. Informative References 618 [I-D.ietf-rtgwg-bgp-pic] 619 Bashandy, A., Filsfils, C., and P. Mohapatra, "BGP Prefix 620 Independent Convergence", draft-ietf-rtgwg-bgp-pic-13 621 (work in progress), February 2021. 623 Authors' Addresses 625 Peter Psenak (editor) 626 Cisco Systems 627 Pribinova Street 10 628 Bratislava 81109 629 Slovakia 631 Email: ppsenak@cisco.com 633 Les Ginsberg 634 Cisco Systems 635 821 Alder Drive 636 Milpitas, CA 95035 637 USA 639 Email: ginsberg@cisco.com 641 Ketan Talaulikar 642 Cisco Systems 643 S.No. 154/6, Phase I, Hinjawadi 644 PUNE, MAHARASHTRA 411 057 645 India 647 Email: ketant@cisco.com