idnits 2.17.1 draft-white-openfabric-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 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 (March 3, 2017) is 2604 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 520, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-10 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-11 Summary: 2 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 3 Internet-Draft S. Zandi 4 Intended status: Informational LinkedIn 5 Expires: September 4, 2017 March 3, 2017 7 OpenFabric 8 draft-white-openfabric-00 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 Sytem 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 September 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Modified Adjacency Formation . . . . . . . . . . . . . . . . 6 72 3. Determining Location on the Fabric . . . . . . . . . . . . . 6 73 3.1. Determining T0 . . . . . . . . . . . . . . . . . . . . . 7 74 3.2. Determining T1 and above . . . . . . . . . . . . . . . . 8 75 4. Flooding Optimization . . . . . . . . . . . . . . . . . . . . 9 76 5. OpenFabric and Route Aggregation . . . . . . . . . . . . . . 10 77 6. OpenFabric and Route Aggregation . . . . . . . . . . . . . . 10 78 7. OpenFabric Modifications to the IS-IS protocol . . . . . . . 11 79 7.1. The Tier Level sub-TLV . . . . . . . . . . . . . . . . . 11 80 7.2. The Do Not Reflood (DNR) bit . . . . . . . . . . . . . . 11 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 9.2. Informative References . . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 Spine and leaf fabrics are often used in large scale data centers; in 90 this application, they are commonly called a fabric because of their 91 regular structure and predicitable forwarding and convergence 92 properties. This document descibes modifications to the IS-IS 93 protocol to enable it to run efficiently on a large scale spine and 94 leaf fabric, OpenFabric. The goals of this control plane are: 96 o Provide a full view of the topology from a single point in the 97 network to simplify operations 99 o Minimize configuration of each router (or switch) in the network 101 o Optimize the operation of IS-IS within a spine and leaf fabric to 102 enable scaling 104 In building any scalable system, it is often best to begin by 105 removing what is not needed. In this spirit, OpenFabric 106 implementations MAY remove the following from IS-IS: 108 o Multilevel flooding domain support. The modifications described 109 in this document will not work across multiple flooding domains. 110 It is assumed that multiple fabrics will be connected through an 111 Exterior Gateway Protocol (EGP), specifically BGP [RFC4271]. 113 o All mutliaccess link processing, including Designated Intermediate 114 Systems (DIS). Spine and leaf fabrics are normally built using 115 only point-to-point links, so multiaccess link processing is not 116 required in OpenFabric. 118 o External metrics. There is no need for external metrics in large 119 scale spine and leaf fabrics; it is assumed that metrics will be 120 properly configured by the operator to account for the correct 121 order of route preference at any route redistribution point. 123 o Tags and traffic engineering processing. OpenFabric is only 124 designed to provide topology and reachability information. It is 125 not designed to provide for traffic engineering, route preference 126 through tags, or other policy mechanisms. It is assumed that all 127 routing policy will be provided through an overlay system which 128 communicates directly with each router in the fabric, such as PCEP 129 [RFC5440] or I2RS [RFC7921]. Traffic engineering is assumed to be 130 provided through Segment Routing (SR) 131 [I-D.ietf-spring-segment-routing]. 133 To create a scalable link state fabric, OpenFabric includes the 134 following: 136 o A slightly modified adjacency formation process. This is largely 137 a matter of forming adjacencies in a specific order, rather than 138 forming an adjacency with every discovered neighbor at the same 139 time. 141 o A mechanism for determining which tier within a spine and leaf 142 fabric in which the router is located. 144 o A mechanism that reduces flooding to the minimum possible, while 145 still ensuring complete database synchronization among the routers 146 within the fabric. 148 o New sub-TLVs to carry OpenFabric specific information; 149 specifically a new IS reachability tier sub-TLV. 151 OpenFabric implementations: 153 o MUST support [RFC5301] and enable hostname advertisement by 154 default if a hostname is configured on the intermediate system. 156 o MUST support [RFC5311], simplified extension of the link state PDU 157 space for IS-IS. 159 o MUST support [RFC5303] and enable three-way handshakes by default. 161 o MUST use TLV type 135 for carrying IPv4 reachability information, 162 as defined in [RFC5305]. 164 o MUST use TLV type 236 for carrying IPv6 reachability information, 165 as defined in [RFC5308]. 167 o MUST use TLV type 22 for carrying IS reachability information, as 168 defined in [RFC5305]. 170 o SHOULD support [RFC6232], purge originator identification for IS- 171 IS. 173 o SHOULD support Segment Routing (SR). 174 [I-D.ietf-spring-segment-routing] 176 o SHOULD support [I-D.ietf-isis-segment-routing-extensions]. 178 o SHOULD support [RFC3719], section 4, hello padding for IS-IS. 179 Variable hello padding SHOULD NOT be used, as data center fabrics 180 are built using high speed links on which padded hellos will have 181 little performance impact. 183 OpenFabric implementations MUST NOT be mixed with standard IS-IS 184 implementations in operational deployments. OpenFabric and standard 185 IS-IS implementations SHOULD be treated as two separate protocols. 187 The following spine and leaf fabric will be used to describe these 188 modifications. 190 +----+ +----+ +----+ +----+ +----+ +----+ 191 | 1A | | 1B | | 1C | | 1D | | 1E | | 1F | (T0) 192 +----+ +----+ +----+ +----+ +----+ +----+ 194 +----+ +----+ +----+ +----+ +----+ +----+ 195 | 2A | | 2B | | 2C | | 2D | | 2E | | 2F | (T1) 196 +----+ +----+ +----+ +----+ +----+ +----+ 198 +----+ +----+ +----+ +----+ +----+ +----+ 199 | 3A | | 3B | | 3C | | 3D | | 3E | | 3F | (T2) 200 +----+ +----+ +----+ +----+ +----+ +----+ 202 +----+ +----+ +----+ +----+ +----+ +----+ 203 | 4A | | 4B | | 4C | | 4D | | 4E | | 4F | (T1) 204 +----+ +----+ +----+ +----+ +----+ +----+ 206 +----+ +----+ +----+ +----+ +----+ +----+ 207 | 5A | | 5B | | 5C | | 5D | | 5E | | 5F | (T0) 208 +----+ +----+ +----+ +----+ +----+ +----+ 210 Figure 1 212 To reduce confusion (spine and leaf fabrics are difficult to draw in 213 plain text art), this diagram does not contain the connections 214 between devices. The reader should assume that each device in a 215 diven layer is connected to every device in the layer above it. For 216 instance: 218 o 5A is connected to 4A, 4B, 4C, 4D, 4E, and 4F 220 o 5B is connected to 4A, 4B, 4C, 4D, 4E, and 4F 222 o 4A is connected to 3A, 3B, 3C, 3D, 3E, 3F, 5A, 5B, 5C, 5D, 5E, and 223 5F 225 o 4B is connected to 3A, 3B, 3C, 3D, 3E, 3F, 5A, 5B, 5C, 5D, 5E, and 226 5F 228 o etc. 230 The tiers or stages of the fabric are also marked for easier 231 reference. T0 is assumed to be connected to application servers, or 232 rather they are Top of Rack (ToR) routers. The remaining tiers, T1 233 and T2, are connected only to the fabric itself. Note there are no 234 "cross links," or "east west" links in the illustrated fabric. The 235 fabric locality detection mechanism described here will not work if 236 there are cross links running east/west through the fabric. Locality 237 detection may be possible in such a fabric; this is an area for 238 further study. 240 The authors would like to thank Nick Russo, Nikos Triantafillis, 241 Rodny Molina, and Ivan Pepelnjak for their comments and review of the 242 concepts and text of this document. 244 2. Modified Adjacency Formation 246 While adjacency formation is not considered particularly burdensome 247 in IS-IS, it is still useful to reduce the amount of state 248 transferred across the network when connecting a new router to the 249 fabric. Any such optimization is bound to present a tradeoff between 250 several factors; the mechanism described here increases the amount of 251 time required to form adjacencies slightly in order to reduce the 252 total state carried across the network. The process is: 254 o An IS connected to the fabric will send hellos on all links. 256 o The IS will only complete the threeway handshake with one newly 257 discovered neighbor; this would normally be the first neighbor 258 which sends the newly connected intermediate system's ID back in 259 the three-way handshake process. 261 o The IS will complete its databse exchange with this one newly 262 adjacent neighbor. 264 o Once this process is completed, the IS will continue processing 265 the remaining neighbors as normal. 267 This process allows each IS newly added to the fabric to exchange a 268 full table once; a very minimal amount of information will be 269 transferred with the remaining neighbors to reach full 270 synchronization. 272 3. Determining Location on the Fabric 274 The tier to which a router is connected is useful to enable 275 autoconfiguration of routers connected to the fabric, and to reduce 276 flooding. This section describes mechanisms for determining the tier 277 at which a router is connected in the fabric in several steps. The 278 first step is to find the Farthest Distance (FD) and the Total 279 Distance (TD), which are useful in this process. To find the FD and 280 TD: 282 o Calculate a Shortest Path Tree (SPT) for the entire network with 283 all link metrics set to 1; this has the effect of calculating a 284 tree based only on hop count 286 o Find one node that is the farthest from the local node in the 287 resulting tree; call this node F, and the distance to this node FD 289 o Calculate an SPT for the entire network with all link metrics set 290 to 1 from the perspective of F; call this TD 292 3.1. Determining T0 294 If FD == TD == 2, this is a three stage fabric; it is not possible to 295 determine the tier at which the local node is located based on any 296 calculation, because the topology is perfectly symmetric. In this 297 case: 299 o The T0 routers MAY be manually configured to advertise 0x00 in 300 their IS reachability tier sub-TLV, indicating they are at the 301 edge of the fabric (a ToR router). 303 o The T0 routers MAY detect that they are T0 through the the 304 presence connected hosts (i.e. through a request for address 305 assignment or some other means). This means of detection may not 306 be reliable in all operational environments, and SHOULD be used 307 with care. If such detection is used, and the router determines 308 it is located at T0, it should advertise 0x00 in its IS 309 reachability tier sub-TLV. 311 o The router MAY examine the IS reachability tier sub-TLV of 312 directly connected neighbors and determine one or more is 313 advertising 0x1 in its IS reachability tier sub-TLVs. This would 314 be the case if the spine routers in a three stage spine and leaf 315 fabric are manually configured to advertise their tier as 0x1. 317 o If there is no way to determine whether or not the local device is 318 in T0 or T1, it MUST advertise 0xFF in its IS reachability tier 319 sub-TLV. 321 If FD == TD, and TD >= 4, this is a greater than three stage fabric; 322 the local device SHOULD advertise 0x00 in its IS reachability tier 323 sub-TLV. 325 For instance, in the diagram above, 1A would: 327 o Calculate an SPT with all link metrics set to 1; on this SPT, 5A 328 through 5F would all have a distance of 4 330 o Select one of these nodes as F; assume 5F is chosen as F 332 o Set FD to 4, the distance to 5F 333 o Run SPF from the perspective of 5F with all link metrics set to 1 335 o Set TD to 4, the cost from 5F to 1A 337 o TD - FD == 0, so 1A is at T0, and is a ToR 339 3.2. Determining T1 and above 341 If FD == TD == 2, this is a three stage fabric; it is not possible to 342 determine the tier at which the local node is located based on any 343 calculation, because the topology is perfectly symmetric. In this 344 case: 346 o The T1 routers MAY be manually configured to advertise 0x01 in 347 their IS reachability tier sub-TLV. 349 o The router MAY examine the IS reachability tier sub-TLV of 350 directly connected neighbors and determine that one or more is 351 advertising 0x00 in its IS reachability tier sub-TLVs. This would 352 be the case if the ToR routers in a three stage spine and leaf 353 fabric are manually configured to advertise their tier as 0x00. 355 o If there is no way to determine whether or not the local device is 356 in T0 or T1, it should advertise 0xFF in its IS reachability tier 357 sub-TLV. 359 If TD != FD, this is a greater than three stage fabric; the local 360 device SHOULD advertise (TD - FD) in its IS reachability tier sub- 361 TLV. 363 For example, in the above five stage fabric, 3B would: 365 o Calculate an SPT with all link metrics set to 1; on this SPT, 5A 366 through 5F and 1A through 1F would all have a cost of 2 368 o Select one of these nodes as F; assume 5F is chosen as F 370 o Set FD to 2, the distance to 5F 372 o Run SPF from the perspective of 5F with all link metrics set to 1 374 o Set TD to 4, the cost from 5F to 1A 376 o TD - FD == 2, so 1A is at T2, and is a spine switch 378 4. Flooding Optimization 380 Flooding is perhaps the most challenging scaling issue for a link 381 state protocol running on a dense, large scale fabric. To reduce 382 flooding, OpenFabric takes advantage of information already available 383 in the link state protocol, the list of the local intermediate 384 system's neighbor's neighbors, and the fabric locality computed 385 above. The following tables are required to compute a set of 386 reflooders: 388 o NL list: The set of neighbors 390 o NN list: The set of neighbor's neighbors; this can be calculated 391 by running SPF truncated to two hops 393 o DNR list: The set of neighbors who should have LSPs (or fragments) 394 marked Do Not Reflood (DNR) 396 o RF list: The set of neighbors who should flood LSPs (or fragments) 397 to their adjacent neighbors to ensure synchronization 399 NL is set to contain all neighbors, and sorted deterministically (for 400 instance, from the highest router ID to the lowest). All 401 intermediate systems within a single fabric SHOULD use the same 402 mechanism for sorting the NL list. NN is set to contain all 403 neighbor's neighbors, or all intermediate systems that are two hops 404 away, as determined by performing a truncated SPF. The DNR and RF 405 tables are initially empty. To begin: 407 o Move any IS in NL with its tier (or fabric location) set to T0 to 408 DNR 410 o If the LSP was received from an IS at a higher tier than the local 411 IS, remove all intermediate systems from NL that are in the same 412 tier as the IS the new LSP was received from 414 Then, for every IS in NL: 416 o If the current entry in NL is connected to any entries in NN: 418 * Move the IS to RF 420 * Remove the intermediate systems connected to the IS from NN 422 o Else move the IS to DNR 424 When flooding, LSPs transmitted to adjacent neighbors on the RF list 425 will be transmitted normally. Adjacent intermediate systems on this 426 list will reflood received LSPs into the next stage of the topology, 427 ensuring database synchronization. LSPs transmitted to adjacent 428 neighbors on the DNR list, however, will have the DNR bit the 429 optional flooding sub-TLV (see the packet format modifications and 430 TLVs below). 432 Any IS receiving an LSP with the DNR bit set will not set the Send 433 Route Message (SRM) flag on any interface for this LSP; hence the LSP 434 will not be reflooded by this IS to any adjacent neighbor. This 435 reduces flooding to the minimum possible while retaining full Link 436 State Database (LSDB) synchronization. 438 5. OpenFabric and Route Aggregation 440 In data center fabrics, ToR routers SHOULD NOT be used to transit 441 between two T1 (or above) spine routers. The simplest way to prevent 442 this is to set the overload bit [RFC3277] for all the LSPs originated 443 from T0 routers. However, this solution would have the unfortunate 444 side effect of causing all reachability beyond any T0 router to have 445 the same metric, and many implementations treat a set overload bit as 446 a metric of 0xFFFF in calculating the Shortest Path Tree (SPT). This 447 document proposes an alternate solution which preserves the leaf node 448 metric, while still avoiding transiting T0 routers. 450 Specifically, all T0 routers SHOULD advertise their metric to reach 451 any T1 adjacent neighbor with a cost of 0XFFE. T1 routers, on the 452 other hand, will advertise T0 routers with the actual interface cost 453 used to reach the T0 router. Hence, links connecting T0 and T1 454 routers will be advertised with an assymetric cost that discourages 455 transiting T0 routers, while leaving reachability to the destinations 456 attached to T0 devices the same. 458 6. OpenFabric and Route Aggregation 460 While aggregation is not recommended in OpenFabric deployments, 461 aggregation MAY take place when routing information is being 462 transmitted from higher level tiers to lower level tiers. For 463 instance, in the example network, 2A through 2F could advertise a 464 single default route to 1A through 1F. 2A through 2F would simply 465 advertise the default as if it were an attached to each router 466 locally using either a type 135 or 236 TLV, and then block TLVs that 467 contain reachability information (such as types 135 and 236). Type 468 22 TLVs, however, MUST be flooded through this boundary, so that 469 every router in the network shares a common view of the topology. 471 Note that aggregation in a DC fabric can result in routing black 472 holes in some cases, and also possibly reduce the efficiency of 473 traffic engineering in the network. 475 7. OpenFabric Modifications to the IS-IS protocol 477 7.1. The Tier Level sub-TLV 479 A new sub-TLV is added to the type 22 TLV to indicate tier level, as 480 follows: 482 o sub-TLV number (one octet): TBA 484 o Tier identifier (one octet) 486 The tier identifier field contains the tier number of the local 487 router as calculated using the process above. If the tier number is 488 unknown, the sub-TLV MUST be included with a tier ID of 0xFF, which 489 indicates the advertising router does not have enough information to 490 calculate its tier number, or there is some error in calculating a 491 tier number. 493 7.2. The Do Not Reflood (DNR) bit 495 For OpenFabric implementations, the Partition Repair in the LSP PDU 496 header SHALL be treated as the Do Not Reflood (DNR) bit. Any IS 497 receiving an LSP with the DNR bit set SHOULD NOT set the SRM flag for 498 the LSP, so the LSP will not be flooded to adjacent routers. 500 8. Security Considerations 502 This document outlines modifications to the IS-IS protocol for 503 operation on large scale data center fabrics. While it does add new 504 TLVs, and some local processing changes, it does not add any new 505 security vulnerabilities to the operation of IS-IS. However, 506 OpenFabric implementions SHOULD implement IS-IS cryptographic 507 authentication, as described in [RFC5304], and should enable other 508 security measures in accordance with best common practices for the 509 IS-IS protocol. 511 9. References 513 9.1. Normative References 515 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 516 Requirement Levels", BCP 14, RFC 2119, 517 DOI 10.17487/RFC2119, March 1997, 518 . 520 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 521 DOI 10.17487/RFC2629, June 1999, 522 . 524 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 525 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 526 October 2008, . 528 [RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way 529 Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, 530 DOI 10.17487/RFC5303, October 2008, 531 . 533 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 534 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 535 2008, . 537 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 538 DOI 10.17487/RFC5308, October 2008, 539 . 541 [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. 542 Shand, "Simplified Extension of Link State PDU (LSP) Space 543 for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, 544 . 546 9.2. Informative References 548 [I-D.ietf-isis-segment-routing-extensions] 549 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 550 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 551 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 552 segment-routing-extensions-10 (work in progress), February 553 2017. 555 [I-D.ietf-spring-segment-routing] 556 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 557 and R. Shakir, "Segment Routing Architecture", draft-ietf- 558 spring-segment-routing-11 (work in progress), February 559 2017. 561 [RFC3277] McPherson, D., "Intermediate System to Intermediate System 562 (IS-IS) Transient Blackhole Avoidance", RFC 3277, 563 DOI 10.17487/RFC3277, April 2002, 564 . 566 [RFC3719] Parker, J., Ed., "Recommendations for Interoperable 567 Networks using Intermediate System to Intermediate System 568 (IS-IS)", RFC 3719, DOI 10.17487/RFC3719, February 2004, 569 . 571 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 572 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 573 DOI 10.17487/RFC4271, January 2006, 574 . 576 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 577 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 578 2008, . 580 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 581 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 582 DOI 10.17487/RFC5440, March 2009, 583 . 585 [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 586 Originator Identification TLV for IS-IS", RFC 6232, 587 DOI 10.17487/RFC6232, May 2011, 588 . 590 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 591 Nadeau, "An Architecture for the Interface to the Routing 592 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 593 . 595 Authors' Addresses 597 Russ White 598 LinkedIn 599 Oak Island, NC 28465 600 USA 602 Email: russ@riw.us 604 Shawn Zandi 605 LinkedIn 606 San Francisco, CA XXXXX 607 USA 609 Email: szandi@linkedin.com