idnits 2.17.1 draft-white-openfabric-02.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 2, 2017) is 2578 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 566, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Obsolete normative reference: RFC 5316 (Obsoleted by RFC 9346) == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-11 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-11 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. White, Ed. 3 Internet-Draft S. Zandi, Ed. 4 Intended status: Informational LinkedIn 5 Expires: October 4, 2017 April 2, 2017 7 Openfabric 8 draft-white-openfabric-02 10 Abstract 12 Spine and leaf topologies are widely used in hyperscale and cloud 13 scale networks. In most of these networks, configuration is 14 automated, but difficult, and topology information is extracted 15 through broad based connections. Policy is often integrated into the 16 control plane, as well, making configuration, management, and 17 troubleshooting difficult. Openfabric is an adaptation of an 18 existing, widely deployed link state protocol, Intermediate System to 19 Intermediate System (IS-IS) that is designed to: 21 o Provide a full view of the topology from a single point in the 22 network to simplify operations 24 o Minimize configuration of each router (or switch) in the network 26 o Optimize the operation of IS-IS within a spine and leaf fabric to 27 enable scaling 29 This document begins with an overview of openfabric, including a 30 description of what may be removed from IS-IS to enable scaling. The 31 document then describes an optimized adjacency formation process; an 32 optimized flooding scheme; some thoughts on the operation of 33 openfabric, metrics, and aggregation; and finally a description of 34 the changes to the IS-IS protocol required for openfabric. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on October 4, 2017. 53 Copyright Notice 55 Copyright (c) 2017 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.2. Contributors . . . . . . . . . . . . . . . . . . . . . . 3 73 1.3. Simplification . . . . . . . . . . . . . . . . . . . . . 3 74 1.4. Additions and Requirements . . . . . . . . . . . . . . . 4 75 1.5. Sample Network . . . . . . . . . . . . . . . . . . . . . 5 76 2. Modified Adjacency Formation . . . . . . . . . . . . . . . . 7 77 3. Determining Location on the Fabric . . . . . . . . . . . . . 7 78 3.1. Determining T0 . . . . . . . . . . . . . . . . . . . . . 8 79 3.2. Determining T1 and above . . . . . . . . . . . . . . . . 9 80 4. Flooding Optimization . . . . . . . . . . . . . . . . . . . . 9 81 4.1. Flooding Failures . . . . . . . . . . . . . . . . . . . . 11 82 5. Other Optimizations . . . . . . . . . . . . . . . . . . . . . 11 83 5.1. Transit Link Reachability . . . . . . . . . . . . . . . . 11 84 5.2. Transiting T0 Routers . . . . . . . . . . . . . . . . . . 11 85 6. Openfabric and Route Aggregation . . . . . . . . . . . . . . 12 86 7. Openfabric Modifications to the IS-IS protocol . . . . . . . 12 87 7.1. Advertising Tier Level . . . . . . . . . . . . . . . . . 12 88 7.2. Do Not Reflood (DNR) . . . . . . . . . . . . . . . . . . 12 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 92 9.2. Informative References . . . . . . . . . . . . . . . . . 14 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 95 1. Introduction 97 1.1. Goals 99 Spine and leaf fabrics are often used in large scale data centers; in 100 this application, they are commonly called a fabric because of their 101 regular structure and predictable forwarding and convergence 102 properties. This document describes modifications to the IS-IS 103 protocol to enable it to run efficiently on a large scale spine and 104 leaf fabric, openfabric. The goals of this control plane are: 106 o Provide a full view of the topology from a single point in the 107 network to simplify operations 109 o Minimize configuration of each router (or switch) in the network 111 o Optimize the operation of IS-IS within a spine and leaf fabric to 112 enable scaling 114 1.2. Contributors 116 The following people have contributed to this draft: Nikos 117 Triantafillis (reflected flooding optimization), Ivan Pepelnjak 118 (three stage fabric modifications), Hannes Gredler (do not reflood 119 optimizations), Les Ginsberg (capabilities encoding, circuit local 120 reflooding), Naiming Shen (capabilities encoding, circuit local 121 reflooding), Uma Chunduri (failure mode suggestions, flooding), Nick 122 Russo, and Rodny Molina. 124 See [RFC5449], [RFC5614], and [RFC7182] for similar solutions in the 125 Mobile Ad Hoc Networking (MANET) solution space. 127 1.3. Simplification 129 In building any scalable system, it is often best to begin by 130 removing what is not needed. In this spirit, openfabric 131 implementations MAY remove the following from IS-IS: 133 o Multilevel flooding domain support. The modifications described 134 in this document will not work across multiple flooding domains. 135 It is assumed that multiple fabrics will be connected through an 136 Exterior Gateway Protocol (EGP), specifically BGP [RFC4271]. 138 o All mutliaccess link processing, including Designated Intermediate 139 Systems (DIS). Spine and leaf fabrics are normally built using 140 only point-to-point links, so multiaccess link processing is not 141 required in openfabric. 143 o External metrics. There is no need for external metrics in large 144 scale spine and leaf fabrics; it is assumed that metrics will be 145 properly configured by the operator to account for the correct 146 order of route preference at any route redistribution point. 148 o Tags and traffic engineering processing. Openfabric is only 149 designed to provide topology and reachability information. It is 150 not designed to provide for traffic engineering, route preference 151 through tags, or other policy mechanisms. It is assumed that all 152 routing policy will be provided through an overlay system which 153 communicates directly with each router in the fabric, such as PCEP 154 [RFC5440] or I2RS [RFC7921]. Traffic engineering is assumed to be 155 provided through Segment Routing (SR) 156 [I-D.ietf-spring-segment-routing]. 158 1.4. Additions and Requirements 160 To create a scalable link state fabric, openfabric includes the 161 following: 163 o A slightly modified adjacency formation process. This is largely 164 a matter of forming adjacencies in a specific order, rather than 165 forming an adjacency with every discovered neighbor at the same 166 time. 168 o A mechanism for determining which tier within a spine and leaf 169 fabric in which the router is located. 171 o A mechanism that reduces flooding to the minimum possible, while 172 still ensuring complete database synchronization among the routers 173 within the fabric. 175 o New sub-TLVs to carry openfabric specific information; 176 specifically a new IS reachability tier sub-TLV. 178 Openfabric implementations: 180 o MUST support [RFC5301] and enable hostname advertisement by 181 default if a hostname is configured on the intermediate system. 183 o MUST support [RFC5311], simplified extension of the link state PDU 184 space for IS-IS. 186 o MUST support [RFC5303] and enable three-way handshakes by default. 188 o MUST use TLV type 135 for carrying IPv4 reachability information, 189 as defined in [RFC5305]. 191 o MUST use TLV type 236 for carrying IPv6 reachability information, 192 as defined in [RFC5308]. 194 o MUST use TLV type 22 for carrying IS reachability information, as 195 defined in [RFC5305]. 197 o SHOULD support [RFC6232], purge originator identification for IS- 198 IS. 200 o SHOULD support Segment Routing (SR). 201 [I-D.ietf-spring-segment-routing] 203 o SHOULD support [I-D.ietf-isis-segment-routing-extensions]. 205 o SHOULD support [RFC3719], section 4, hello padding for IS-IS. 206 Variable hello padding SHOULD NOT be used, as data center fabrics 207 are built using high speed links on which padded hellos will have 208 little performance impact. 210 Openfabric implementations MUST NOT be mixed with standard IS-IS 211 implementations in operational deployments. Openfabric and standard 212 IS-IS implementations SHOULD be treated as two separate protocols. 214 1.5. Sample Network 216 The following spine and leaf fabric will be used to describe these 217 modifications. 219 +----+ +----+ +----+ +----+ +----+ +----+ 220 | 1A | | 1B | | 1C | | 1D | | 1E | | 1F | (T0) 221 +----+ +----+ +----+ +----+ +----+ +----+ 223 +----+ +----+ +----+ +----+ +----+ +----+ 224 | 2A | | 2B | | 2C | | 2D | | 2E | | 2F | (T1) 225 +----+ +----+ +----+ +----+ +----+ +----+ 227 +----+ +----+ +----+ +----+ +----+ +----+ 228 | 3A | | 3B | | 3C | | 3D | | 3E | | 3F | (T2) 229 +----+ +----+ +----+ +----+ +----+ +----+ 231 +----+ +----+ +----+ +----+ +----+ +----+ 232 | 4A | | 4B | | 4C | | 4D | | 4E | | 4F | (T1) 233 +----+ +----+ +----+ +----+ +----+ +----+ 235 +----+ +----+ +----+ +----+ +----+ +----+ 236 | 5A | | 5B | | 5C | | 5D | | 5E | | 5F | (T0) 237 +----+ +----+ +----+ +----+ +----+ +----+ 239 Figure 1 241 To reduce confusion (spine and leaf fabrics are difficult to draw in 242 plain text art), this diagram does not contain the connections 243 between devices. The reader should assume that each device in a 244 given layer is connected to every device in the layer above it. For 245 instance: 247 o 5A is connected to 4A, 4B, 4C, 4D, 4E, and 4F 249 o 5B is connected to 4A, 4B, 4C, 4D, 4E, and 4F 251 o 4A is connected to 3A, 3B, 3C, 3D, 3E, 3F, 5A, 5B, 5C, 5D, 5E, and 252 5F 254 o 4B is connected to 3A, 3B, 3C, 3D, 3E, 3F, 5A, 5B, 5C, 5D, 5E, and 255 5F 257 o etc. 259 The tiers or stages of the fabric are also marked for easier 260 reference. T0 is assumed to be connected to application servers, or 261 rather they are Top of Rack (ToR) routers. The remaining tiers, T1 262 and T2, are connected only to the fabric itself. Note there are no 263 "cross links," or "east west" links in the illustrated fabric. The 264 fabric locality detection mechanism described here will not work if 265 there are cross links running east/west through the fabric. Locality 266 detection may be possible in such a fabric; this is an area for 267 further study. 269 2. Modified Adjacency Formation 271 While adjacency formation is not considered particularly burdensome 272 in IS-IS, it is still useful to reduce the amount of state 273 transferred across the network when connecting a new router to the 274 fabric. Any such optimization is bound to present a tradeoff between 275 several factors; the mechanism described here increases the amount of 276 time required to form adjacencies slightly in order to reduce the 277 total state carried across the network. The process is: 279 o An IS connected to the fabric will send hellos on all links. 281 o The IS will only complete the three-way handshake with one newly 282 discovered neighbor; this would normally be the first neighbor 283 which sends the newly connected intermediate system's ID back in 284 the three-way handshake process. 286 o The IS will complete its database exchange with this one newly 287 adjacent neighbor. 289 o Once this process is completed, the IS will continue processing 290 the remaining neighbors as normal. 292 This process allows each IS newly added to the fabric to exchange a 293 full table once; a very minimal amount of information will be 294 transferred with the remaining neighbors to reach full 295 synchronization. 297 3. Determining Location on the Fabric 299 The tier to which a router is connected is useful to enable 300 autoconfiguration of routers connected to the fabric, and to reduce 301 flooding. This section describes mechanisms for determining the tier 302 at which a router is connected in the fabric in several steps. The 303 first step is to find the Farthest Distance (FD) and the Total 304 Distance (TD), which are useful in this process. To find the FD and 305 TD: 307 o Calculate a Shortest Path Tree (SPT) for the entire network with 308 all link metrics set to 1; this has the effect of calculating a 309 tree based only on hop count 311 o Find one node that is the farthest from the local node in the 312 resulting tree; call this node F, and the distance to this node FD 314 o Calculate an SPT for the entire network with all link metrics set 315 to 1 from the perspective of F; call this TD 317 3.1. Determining T0 319 If FD == TD == 2, this is a three stage fabric; it is not possible to 320 determine the tier at which the local node is located based on any 321 calculation, because the topology is perfectly symmetric. In this 322 case: 324 o The T0 routers MAY be manually configured to advertise 0x00 in 325 their IS reachability tier sub-TLV, indicating they are at the 326 edge of the fabric (a ToR router). 328 o The T0 routers MAY detect that they are T0 through the presence 329 connected hosts (i.e. through a request for address assignment or 330 some other means). This means of detection may not be reliable in 331 all operational environments, and SHOULD be used with care. If 332 such detection is used, and the router determines it is located at 333 T0, it should advertise 0x00 in its IS reachability tier sub-TLV. 335 o The router MAY examine the IS reachability tier sub-TLV of 336 directly connected neighbors and determine one or more is 337 advertising 0x1 in its IS reachability tier sub-TLVs. This would 338 be the case if the spine routers in a three stage spine and leaf 339 fabric are manually configured to advertise their tier as 0x1. 341 o If there is no way to determine whether or not the local device is 342 in T0 or T1, it MUST advertise 0xFF in its IS reachability tier 343 sub-TLV. 345 If FD == TD, and TD >= 4, this is a greater than three stage fabric; 346 the local device SHOULD advertise 0x00 in its IS reachability tier 347 sub-TLV. 349 For instance, in the diagram above, 1A would: 351 o Calculate an SPT with all link metrics set to 1; on this SPT, 5A 352 through 5F would all have a distance of 4 354 o Select one of these nodes as F; assume 5F is chosen as F 356 o Set FD to 4, the distance to 5F 358 o Run SPF from the perspective of 5F with all link metrics set to 1 360 o Set TD to 4, the cost from 5F to 1A 361 o TD - FD == 0, so 1A is at T0, and is a ToR 363 3.2. Determining T1 and above 365 If FD == TD == 2, this is a three stage fabric; it is not possible to 366 determine the tier at which the local node is located based on any 367 calculation, because the topology is perfectly symmetric. In this 368 case: 370 o The T1 routers MAY be manually configured to advertise 0x01 in 371 their IS reachability tier sub-TLV. 373 o The router MAY examine the IS reachability tier sub-TLV of 374 directly connected neighbors and determine that one or more is 375 advertising 0x00 in its IS reachability tier sub-TLVs. This would 376 be the case if the ToR routers in a three stage spine and leaf 377 fabric are manually configured to advertise their tier as 0x00. 379 o If there is no way to determine whether or not the local device is 380 in T0 or T1, it should advertise 0xFF in its IS reachability tier 381 sub-TLV. 383 If TD != FD, this is a greater than three stage fabric; the local 384 device SHOULD advertise (TD - FD) in its IS reachability tier sub- 385 TLV. 387 For example, in the above five stage fabric, 3B would: 389 o Calculate an SPT with all link metrics set to 1; on this SPT, 5A 390 through 5F and 1A through 1F would all have a cost of 2 392 o Select one of these nodes as F; assume 5F is chosen as F 394 o Set FD to 2, the distance to 5F 396 o Run SPF from the perspective of 5F with all link metrics set to 1 398 o Set TD to 4, the cost from 5F to 1A 400 o TD - FD == 2, so 1A is at T2, and is a spine switch 402 4. Flooding Optimization 404 Flooding is perhaps the most challenging scaling issue for a link 405 state protocol running on a dense, large scale fabric. To reduce 406 flooding, Openfabric takes advantage of information already available 407 in the link state protocol, the list of the local intermediate 408 system's neighbor's neighbors, and the fabric locality computed 409 above. The following tables are required to compute a set of 410 reflooders: 412 o NL list: The set of neighbors 414 o NN list: The set of neighbor's neighbors; this can be calculated 415 by running SPF truncated to two hops 417 o DNR list: The set of neighbors who should have LSPs (or fragments) 418 marked Do Not Reflood (DNR) 420 o RF list: The set of neighbors who should flood LSPs (or fragments) 421 to their adjacent neighbors to ensure synchronization 423 NL is set to contain all neighbors, and sorted deterministically (for 424 instance, from the highest router ID to the lowest). All 425 intermediate systems within a single fabric SHOULD use the same 426 mechanism for sorting the NL list. NN is set to contain all 427 neighbor's neighbors, or all intermediate systems that are two hops 428 away, as determined by performing a truncated SPF. The DNR and RF 429 tables are initially empty. To begin, the following steps are taken 430 to reduce the size of NN and NL: 432 o Move any IS in NL with its tier (or fabric location) set to T0 to 433 DNR 435 o Remove all intermediate systems from NL and NN that in the 436 shortest path to the IS that originated the LSP 438 Then, for every IS in NL: 440 o If the current entry in NL is connected to any entries in NN: 442 * Move the IS to RF 444 * Remove the intermediate systems connected to the IS from NN 446 o Else move the IS to DNR 448 When flooding, LSPs transmitted to adjacent neighbors on the RF list 449 will be transmitted normally. Adjacent intermediate systems on this 450 list will reflood received LSPs into the next stage of the topology, 451 ensuring database synchronization. LSPs transmitted to adjacent 452 neighbors on the DNR list, however, will be transmitted to the DNR 453 address (see modifications to the IS-IS protocol, below). 455 Any IS receiving a link state packet transmitted to the DNR address 456 SHOULD NOT set the Send Route Message (SRM) flag on any interface for 457 this LSP; hence the LSP will not be reflooded by this IS to any 458 adjacent neighbor. This reduces flooding to the minimum possible 459 while retaining full Link State Database (LSDB) synchronization. 461 4.1. Flooding Failures 463 It is possible in some failure modes for flooding to be incomplete 464 because of the flooding optimizations outlined. Specifically, if a 465 reflooder fails, or is somehow disconnected from all the links across 466 which it should be reflooding, it is possible an LSP is only 467 partially flooded through the fabric. To prevent such situations, 468 any IS receiving an LSP transmitted using DNR SHOULD: 470 o Set a short timer; the default should be less than one second 472 o When the timer expires, send a Complete Sequence Number Packet 473 (CSNP) to all neighbors 475 o Process any Partial Sequence Number Packets (PSNPs) as required to 476 resynchronize 478 o If a resynchronization is required, notify the network operator 479 through a network management system 481 5. Other Optimizations 483 5.1. Transit Link Reachability 485 In order to reduce the amount of control plane state carried on large 486 scale spine and leaf fabrics, openfabric implementations SHOULD NOT 487 advertise reachability for transit links. These links MAY remain 488 unnumbered, as IS-IS does not require layer 3 IP addresses to 489 operate. Each router SHOULD be configured with a single loopback 490 address, which is assigned an IPv6 address, to provide reachability 491 to routers which make up the fabric. 493 5.2. Transiting T0 Routers 495 In data center fabrics, ToR routers SHOULD NOT be used to transit 496 between two T1 (or above) spine routers. The simplest way to prevent 497 this is to set the overload bit [RFC3277] for all the LSPs originated 498 from T0 routers. However, this solution would have the unfortunate 499 side effect of causing all reachability beyond any T0 router to have 500 the same metric, and many implementations treat a set overload bit as 501 a metric of 0xFFFF in calculating the Shortest Path Tree (SPT). This 502 document proposes an alternate solution which preserves the leaf node 503 metric, while still avoiding transiting T0 routers. 505 Specifically, all T0 routers SHOULD advertise their metric to reach 506 any T1 adjacent neighbor with a cost of 0XFFE. T1 routers, on the 507 other hand, will advertise T0 routers with the actual interface cost 508 used to reach the T0 router. Hence, links connecting T0 and T1 509 routers will be advertised with an asymmetric cost that discourages 510 transiting T0 routers, while leaving reachability to the destinations 511 attached to T0 devices the same. 513 6. Openfabric and Route Aggregation 515 While aggregation is not recommended in openfabric deployments, 516 aggregation MAY take place when routing information is being 517 transmitted from higher level tiers to lower level tiers. For 518 instance, in the example network, 2A through 2F could advertise a 519 single default route to 1A through 1F. 2A through 2F would simply 520 advertise the default as if it were an attached to each router 521 locally using either a type 135 or 236 TLV, and then block TLVs that 522 contain reachability information (such as types 135 and 236). Type 523 22 TLVs, however, MUST be flooded through this boundary, so that 524 every router in the network shares a common view of the topology. 526 Note that aggregation in a DC fabric can result in routing black 527 holes in some cases, and also possibly reduce the efficiency of 528 traffic engineering in the network. 530 7. Openfabric Modifications to the IS-IS protocol 532 7.1. Advertising Tier Level 534 The tier level is carried as a subTLV of the router capabilities TLV 535 described in [RFC7981]. The subTLV number is TBA; the TLV will 536 contain one octet encoding the tier number as an integer. If the 537 openfabric IS only supports IPv6, the procedure described in section 538 3 of [RFC7981] MUST be followed, and an IPv6 address carried in the 539 IPv6 TE Router ID sub-TLV according to [RFC5316]. 541 7.2. Do Not Reflood (DNR) 543 Link state packets MUST be encoded in a circuit scope PDU as 544 described in [RFC7356] 546 8. Security Considerations 548 This document outlines modifications to the IS-IS protocol for 549 operation on large scale data center fabrics. While it does add new 550 TLVs, and some local processing changes, it does not add any new 551 security vulnerabilities to the operation of IS-IS. However, 552 openfabric implementations SHOULD implement IS-IS cryptographic 553 authentication, as described in [RFC5304], and should enable other 554 security measures in accordance with best common practices for the 555 IS-IS protocol. 557 9. References 559 9.1. Normative References 561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 562 Requirement Levels", BCP 14, RFC 2119, 563 DOI 10.17487/RFC2119, March 1997, 564 . 566 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 567 DOI 10.17487/RFC2629, June 1999, 568 . 570 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 571 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 572 October 2008, . 574 [RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way 575 Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, 576 DOI 10.17487/RFC5303, October 2008, 577 . 579 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 580 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 581 2008, . 583 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 584 DOI 10.17487/RFC5308, October 2008, 585 . 587 [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. 588 Shand, "Simplified Extension of Link State PDU (LSP) Space 589 for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, 590 . 592 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 593 Support of Inter-Autonomous System (AS) MPLS and GMPLS 594 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 595 December 2008, . 597 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 598 Scope Link State PDUs (LSPs)", RFC 7356, 599 DOI 10.17487/RFC7356, September 2014, 600 . 602 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 603 for Advertising Router Information", RFC 7981, 604 DOI 10.17487/RFC7981, October 2016, 605 . 607 9.2. Informative References 609 [I-D.ietf-isis-segment-routing-extensions] 610 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 611 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 612 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 613 segment-routing-extensions-11 (work in progress), March 614 2017. 616 [I-D.ietf-spring-segment-routing] 617 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 618 and R. Shakir, "Segment Routing Architecture", draft-ietf- 619 spring-segment-routing-11 (work in progress), February 620 2017. 622 [RFC3277] McPherson, D., "Intermediate System to Intermediate System 623 (IS-IS) Transient Blackhole Avoidance", RFC 3277, 624 DOI 10.17487/RFC3277, April 2002, 625 . 627 [RFC3719] Parker, J., Ed., "Recommendations for Interoperable 628 Networks using Intermediate System to Intermediate System 629 (IS-IS)", RFC 3719, DOI 10.17487/RFC3719, February 2004, 630 . 632 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 633 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 634 DOI 10.17487/RFC4271, January 2006, 635 . 637 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 638 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 639 2008, . 641 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 642 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 643 DOI 10.17487/RFC5440, March 2009, 644 . 646 [RFC5449] Baccelli, E., Jacquet, P., Nguyen, D., and T. Clausen, 647 "OSPF Multipoint Relay (MPR) Extension for Ad Hoc 648 Networks", RFC 5449, DOI 10.17487/RFC5449, February 2009, 649 . 651 [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) 652 Extension of OSPF Using Connected Dominating Set (CDS) 653 Flooding", RFC 5614, DOI 10.17487/RFC5614, August 2009, 654 . 656 [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 657 Originator Identification TLV for IS-IS", RFC 6232, 658 DOI 10.17487/RFC6232, May 2011, 659 . 661 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 662 Check Value and Timestamp TLV Definitions for Mobile Ad 663 Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182, 664 April 2014, . 666 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 667 Nadeau, "An Architecture for the Interface to the Routing 668 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 669 . 671 Authors' Addresses 673 Russ White (editor) 674 LinkedIn 676 Email: russ@riw.us 678 Shawn Zandi (editor) 679 LinkedIn 681 Email: szandi@linkedin.com