idnits 2.17.1 draft-white-openfabric-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 : ---------------------------------------------------------------------------- ** 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Link state packets flooded to the DNR layer 2 (MAC) address TBA SHOULD not be reflooded by receiving intermediate systems. -- The document date (March 27, 2017) is 2585 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 533, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 538, 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-11 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-11 Summary: 2 errors (**), 0 flaws (~~), 7 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 N. Triantafillis 5 Expires: September 28, 2017 LinkedIn 6 H. Gredler 7 RtBrick Inc. 8 March 27, 2017 10 OpenFabric 11 draft-white-openfabric-01 13 Abstract 15 Spine and leaf topologies are widely used in hyperscale and cloud 16 scale networks. In most of these networks, configuration is 17 automated, but difficult, and topology information is extracted 18 through broad based connections. Policy is often integrated into the 19 control plane, as well, making configuration, management, and 20 troubleshooting difficult. OpenFabric is an adaptation of an 21 existing, widely deployed link state protocol, Intermediate Sytem to 22 Intermediate System (IS-IS) that is designed to: 24 o Provide a full view of the topology from a single point in the 25 network to simplify operations 27 o Minimize configuration of each router (or switch) in the network 29 o Optimize the operation of IS-IS within a spine and leaf fabric to 30 enable scaling 32 This document begins with an overview of OpenFabric, including a 33 description of what may be removed from IS-IS to enable scaling. The 34 document then describes an optimized adjacency formation process; an 35 optimized flooding scheme; some thoughts on the operation of 36 OpenFabric, metrics, and aggregation; and finally a description of 37 the changes to the IS-IS protocol required for OpenFabric. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on September 28, 2017. 56 Copyright Notice 58 Copyright (c) 2017 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 2. Modified Adjacency Formation . . . . . . . . . . . . . . . . 6 75 3. Determining Location on the Fabric . . . . . . . . . . . . . 6 76 3.1. Determining T0 . . . . . . . . . . . . . . . . . . . . . 7 77 3.2. Determining T1 and above . . . . . . . . . . . . . . . . 8 78 4. Flooding Optimization . . . . . . . . . . . . . . . . . . . . 9 79 5. Other Optimizations . . . . . . . . . . . . . . . . . . . . . 10 80 5.1. Transit Link Reachability . . . . . . . . . . . . . . . . 10 81 5.2. Transiting T0 Routers . . . . . . . . . . . . . . . . . . 10 82 6. OpenFabric and Route Aggregation . . . . . . . . . . . . . . 10 83 7. OpenFabric Modifications to the IS-IS protocol . . . . . . . 11 84 7.1. The Tier Level sub-TLV . . . . . . . . . . . . . . . . . 11 85 7.2. The Do Not Reflood (DNR) address . . . . . . . . . . . . 11 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 89 9.2. Informative References . . . . . . . . . . . . . . . . . 12 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 92 1. Introduction 94 Spine and leaf fabrics are often used in large scale data centers; in 95 this application, they are commonly called a fabric because of their 96 regular structure and predicitable forwarding and convergence 97 properties. This document descibes modifications to the IS-IS 98 protocol to enable it to run efficiently on a large scale spine and 99 leaf fabric, OpenFabric. The goals of this control plane are: 101 o Provide a full view of the topology from a single point in the 102 network to simplify operations 104 o Minimize configuration of each router (or switch) in the network 106 o Optimize the operation of IS-IS within a spine and leaf fabric to 107 enable scaling 109 In building any scalable system, it is often best to begin by 110 removing what is not needed. In this spirit, OpenFabric 111 implementations MAY remove the following from IS-IS: 113 o Multilevel flooding domain support. The modifications described 114 in this document will not work across multiple flooding domains. 115 It is assumed that multiple fabrics will be connected through an 116 Exterior Gateway Protocol (EGP), specifically BGP [RFC4271]. 118 o All mutliaccess link processing, including Designated Intermediate 119 Systems (DIS). Spine and leaf fabrics are normally built using 120 only point-to-point links, so multiaccess link processing is not 121 required in OpenFabric. 123 o External metrics. There is no need for external metrics in large 124 scale spine and leaf fabrics; it is assumed that metrics will be 125 properly configured by the operator to account for the correct 126 order of route preference at any route redistribution point. 128 o Tags and traffic engineering processing. OpenFabric is only 129 designed to provide topology and reachability information. It is 130 not designed to provide for traffic engineering, route preference 131 through tags, or other policy mechanisms. It is assumed that all 132 routing policy will be provided through an overlay system which 133 communicates directly with each router in the fabric, such as PCEP 134 [RFC5440] or I2RS [RFC7921]. Traffic engineering is assumed to be 135 provided through Segment Routing (SR) 136 [I-D.ietf-spring-segment-routing]. 138 To create a scalable link state fabric, OpenFabric includes the 139 following: 141 o A slightly modified adjacency formation process. This is largely 142 a matter of forming adjacencies in a specific order, rather than 143 forming an adjacency with every discovered neighbor at the same 144 time. 146 o A mechanism for determining which tier within a spine and leaf 147 fabric in which the router is located. 149 o A mechanism that reduces flooding to the minimum possible, while 150 still ensuring complete database synchronization among the routers 151 within the fabric. 153 o New sub-TLVs to carry OpenFabric specific information; 154 specifically a new IS reachability tier sub-TLV. 156 OpenFabric implementations: 158 o MUST support [RFC5301] and enable hostname advertisement by 159 default if a hostname is configured on the intermediate system. 161 o MUST support [RFC5311], simplified extension of the link state PDU 162 space for IS-IS. 164 o MUST support [RFC5303] and enable three-way handshakes by default. 166 o MUST use TLV type 135 for carrying IPv4 reachability information, 167 as defined in [RFC5305]. 169 o MUST use TLV type 236 for carrying IPv6 reachability information, 170 as defined in [RFC5308]. 172 o MUST use TLV type 22 for carrying IS reachability information, as 173 defined in [RFC5305]. 175 o SHOULD support [RFC6232], purge originator identification for IS- 176 IS. 178 o SHOULD support Segment Routing (SR). 179 [I-D.ietf-spring-segment-routing] 181 o SHOULD support [I-D.ietf-isis-segment-routing-extensions]. 183 o SHOULD support [RFC3719], section 4, hello padding for IS-IS. 184 Variable hello padding SHOULD NOT be used, as data center fabrics 185 are built using high speed links on which padded hellos will have 186 little performance impact. 188 OpenFabric implementations MUST NOT be mixed with standard IS-IS 189 implementations in operational deployments. OpenFabric and standard 190 IS-IS implementations SHOULD be treated as two separate protocols. 192 The following spine and leaf fabric will be used to describe these 193 modifications. 195 +----+ +----+ +----+ +----+ +----+ +----+ 196 | 1A | | 1B | | 1C | | 1D | | 1E | | 1F | (T0) 197 +----+ +----+ +----+ +----+ +----+ +----+ 199 +----+ +----+ +----+ +----+ +----+ +----+ 200 | 2A | | 2B | | 2C | | 2D | | 2E | | 2F | (T1) 201 +----+ +----+ +----+ +----+ +----+ +----+ 203 +----+ +----+ +----+ +----+ +----+ +----+ 204 | 3A | | 3B | | 3C | | 3D | | 3E | | 3F | (T2) 205 +----+ +----+ +----+ +----+ +----+ +----+ 207 +----+ +----+ +----+ +----+ +----+ +----+ 208 | 4A | | 4B | | 4C | | 4D | | 4E | | 4F | (T1) 209 +----+ +----+ +----+ +----+ +----+ +----+ 211 +----+ +----+ +----+ +----+ +----+ +----+ 212 | 5A | | 5B | | 5C | | 5D | | 5E | | 5F | (T0) 213 +----+ +----+ +----+ +----+ +----+ +----+ 215 Figure 1 217 To reduce confusion (spine and leaf fabrics are difficult to draw in 218 plain text art), this diagram does not contain the connections 219 between devices. The reader should assume that each device in a 220 given layer is connected to every device in the layer above it. For 221 instance: 223 o 5A is connected to 4A, 4B, 4C, 4D, 4E, and 4F 225 o 5B is connected to 4A, 4B, 4C, 4D, 4E, and 4F 227 o 4A is connected to 3A, 3B, 3C, 3D, 3E, 3F, 5A, 5B, 5C, 5D, 5E, and 228 5F 230 o 4B is connected to 3A, 3B, 3C, 3D, 3E, 3F, 5A, 5B, 5C, 5D, 5E, and 231 5F 233 o etc. 235 The tiers or stages of the fabric are also marked for easier 236 reference. T0 is assumed to be connected to application servers, or 237 rather they are Top of Rack (ToR) routers. The remaining tiers, T1 238 and T2, are connected only to the fabric itself. Note there are no 239 "cross links," or "east west" links in the illustrated fabric. The 240 fabric locality detection mechanism described here will not work if 241 there are cross links running east/west through the fabric. Locality 242 detection may be possible in such a fabric; this is an area for 243 further study. 245 See [RFC5449], [RFC5614], and [RFC7182] for similar solutions in the 246 Mobile Ad Hoc Networking (MANET) solution space. 248 The authors would like to thank Nick Russo, Rodny Molina, and Ivan 249 Pepelnjak for their comments and review of the concepts and text of 250 this document. 252 2. Modified Adjacency Formation 254 While adjacency formation is not considered particularly burdensome 255 in IS-IS, it is still useful to reduce the amount of state 256 transferred across the network when connecting a new router to the 257 fabric. Any such optimization is bound to present a tradeoff between 258 several factors; the mechanism described here increases the amount of 259 time required to form adjacencies slightly in order to reduce the 260 total state carried across the network. The process is: 262 o An IS connected to the fabric will send hellos on all links. 264 o The IS will only complete the three-way handshake with one newly 265 discovered neighbor; this would normally be the first neighbor 266 which sends the newly connected intermediate system's ID back in 267 the three-way handshake process. 269 o The IS will complete its database exchange with this one newly 270 adjacent neighbor. 272 o Once this process is completed, the IS will continue processing 273 the remaining neighbors as normal. 275 This process allows each IS newly added to the fabric to exchange a 276 full table once; a very minimal amount of information will be 277 transferred with the remaining neighbors to reach full 278 synchronization. 280 3. Determining Location on the Fabric 282 The tier to which a router is connected is useful to enable 283 autoconfiguration of routers connected to the fabric, and to reduce 284 flooding. This section describes mechanisms for determining the tier 285 at which a router is connected in the fabric in several steps. The 286 first step is to find the Farthest Distance (FD) and the Total 287 Distance (TD), which are useful in this process. To find the FD and 288 TD: 290 o Calculate a Shortest Path Tree (SPT) for the entire network with 291 all link metrics set to 1; this has the effect of calculating a 292 tree based only on hop count 294 o Find one node that is the farthest from the local node in the 295 resulting tree; call this node F, and the distance to this node FD 297 o Calculate an SPT for the entire network with all link metrics set 298 to 1 from the perspective of F; call this TD 300 3.1. Determining T0 302 If FD == TD == 2, this is a three stage fabric; it is not possible to 303 determine the tier at which the local node is located based on any 304 calculation, because the topology is perfectly symmetric. In this 305 case: 307 o The T0 routers MAY be manually configured to advertise 0x00 in 308 their IS reachability tier sub-TLV, indicating they are at the 309 edge of the fabric (a ToR router). 311 o The T0 routers MAY detect that they are T0 through the the 312 presence connected hosts (i.e. through a request for address 313 assignment or some other means). This means of detection may not 314 be reliable in all operational environments, and SHOULD be used 315 with care. If such detection is used, and the router determines 316 it is located at T0, it should advertise 0x00 in its IS 317 reachability tier sub-TLV. 319 o The router MAY examine the IS reachability tier sub-TLV of 320 directly connected neighbors and determine one or more is 321 advertising 0x1 in its IS reachability tier sub-TLVs. This would 322 be the case if the spine routers in a three stage spine and leaf 323 fabric are manually configured to advertise their tier as 0x1. 325 o If there is no way to determine whether or not the local device is 326 in T0 or T1, it MUST advertise 0xFF in its IS reachability tier 327 sub-TLV. 329 If FD == TD, and TD >= 4, this is a greater than three stage fabric; 330 the local device SHOULD advertise 0x00 in its IS reachability tier 331 sub-TLV. 333 For instance, in the diagram above, 1A would: 335 o Calculate an SPT with all link metrics set to 1; on this SPT, 5A 336 through 5F would all have a distance of 4 338 o Select one of these nodes as F; assume 5F is chosen as F 340 o Set FD to 4, the distance to 5F 342 o Run SPF from the perspective of 5F with all link metrics set to 1 344 o Set TD to 4, the cost from 5F to 1A 346 o TD - FD == 0, so 1A is at T0, and is a ToR 348 3.2. Determining T1 and above 350 If FD == TD == 2, this is a three stage fabric; it is not possible to 351 determine the tier at which the local node is located based on any 352 calculation, because the topology is perfectly symmetric. In this 353 case: 355 o The T1 routers MAY be manually configured to advertise 0x01 in 356 their IS reachability tier sub-TLV. 358 o The router MAY examine the IS reachability tier sub-TLV of 359 directly connected neighbors and determine that one or more is 360 advertising 0x00 in its IS reachability tier sub-TLVs. This would 361 be the case if the ToR routers in a three stage spine and leaf 362 fabric are manually configured to advertise their tier as 0x00. 364 o If there is no way to determine whether or not the local device is 365 in T0 or T1, it should advertise 0xFF in its IS reachability tier 366 sub-TLV. 368 If TD != FD, this is a greater than three stage fabric; the local 369 device SHOULD advertise (TD - FD) in its IS reachability tier sub- 370 TLV. 372 For example, in the above five stage fabric, 3B would: 374 o Calculate an SPT with all link metrics set to 1; on this SPT, 5A 375 through 5F and 1A through 1F would all have a cost of 2 377 o Select one of these nodes as F; assume 5F is chosen as F 379 o Set FD to 2, the distance to 5F 381 o Run SPF from the perspective of 5F with all link metrics set to 1 383 o Set TD to 4, the cost from 5F to 1A 385 o TD - FD == 2, so 1A is at T2, and is a spine switch 387 4. Flooding Optimization 389 Flooding is perhaps the most challenging scaling issue for a link 390 state protocol running on a dense, large scale fabric. To reduce 391 flooding, OpenFabric takes advantage of information already available 392 in the link state protocol, the list of the local intermediate 393 system's neighbor's neighbors, and the fabric locality computed 394 above. The following tables are required to compute a set of 395 reflooders: 397 o NL list: The set of neighbors 399 o NN list: The set of neighbor's neighbors; this can be calculated 400 by running SPF truncated to two hops 402 o DNR list: The set of neighbors who should have LSPs (or fragments) 403 marked Do Not Reflood (DNR) 405 o RF list: The set of neighbors who should flood LSPs (or fragments) 406 to their adjacent neighbors to ensure synchronization 408 NL is set to contain all neighbors, and sorted deterministically (for 409 instance, from the highest router ID to the lowest). All 410 intermediate systems within a single fabric SHOULD use the same 411 mechanism for sorting the NL list. NN is set to contain all 412 neighbor's neighbors, or all intermediate systems that are two hops 413 away, as determined by performing a truncated SPF. The DNR and RF 414 tables are initially empty. To begin, the following steps are taken 415 to reduce the size of NN and NL: 417 o Move any IS in NL with its tier (or fabric location) set to T0 to 418 DNR 420 o Remove all intermediate systems from NL and NN that in the 421 shortest path to the IS that originated the LSP 423 Then, for every IS in NL: 425 o If the current entry in NL is connected to any entries in NN: 427 * Move the IS to RF 429 * Remove the intermediate systems connected to the IS from NN 431 o Else move the IS to DNR 433 When flooding, LSPs transmitted to adjacent neighbors on the RF list 434 will be transmitted normally. Adjacent intermediate systems on this 435 list will reflood received LSPs into the next stage of the topology, 436 ensuring database synchronization. LSPs transmitted to adjacent 437 neighbors on the DNR list, however, will be transmitted to the DNR 438 address (see modifications to the IS-IS protocol, below). 440 Any IS receiving a link state packet transmitted to the DNR address 441 SHOULD NOT set the Send Route Message (SRM) flag on any interface for 442 this LSP; hence the LSP will not be reflooded by this IS to any 443 adjacent neighbor. This reduces flooding to the minimum possible 444 while retaining full Link State Database (LSDB) synchronization. 446 5. Other Optimizations 448 5.1. Transit Link Reachability 450 In order to reduce the amount of control plane state carried on large 451 scale spine and leaf fabrics, openfabric implementations SHOULD NOT 452 advertise reachability for transit links. These links MAY remain 453 unnumbered, as IS-IS does not require layer 3 IP addresses to 454 operate. Each router SHOULD be configured with a single loopback 455 address, which is assigned an IPv6 address, to provide reachability 456 to routers which make up the fabric. 458 5.2. Transiting T0 Routers 460 In data center fabrics, ToR routers SHOULD NOT be used to transit 461 between two T1 (or above) spine routers. The simplest way to prevent 462 this is to set the overload bit [RFC3277] for all the LSPs originated 463 from T0 routers. However, this solution would have the unfortunate 464 side effect of causing all reachability beyond any T0 router to have 465 the same metric, and many implementations treat a set overload bit as 466 a metric of 0xFFFF in calculating the Shortest Path Tree (SPT). This 467 document proposes an alternate solution which preserves the leaf node 468 metric, while still avoiding transiting T0 routers. 470 Specifically, all T0 routers SHOULD advertise their metric to reach 471 any T1 adjacent neighbor with a cost of 0XFFE. T1 routers, on the 472 other hand, will advertise T0 routers with the actual interface cost 473 used to reach the T0 router. Hence, links connecting T0 and T1 474 routers will be advertised with an assymetric cost that discourages 475 transiting T0 routers, while leaving reachability to the destinations 476 attached to T0 devices the same. 478 6. OpenFabric and Route Aggregation 480 While aggregation is not recommended in OpenFabric deployments, 481 aggregation MAY take place when routing information is being 482 transmitted from higher level tiers to lower level tiers. For 483 instance, in the example network, 2A through 2F could advertise a 484 single default route to 1A through 1F. 2A through 2F would simply 485 advertise the default as if it were an attached to each router 486 locally using either a type 135 or 236 TLV, and then block TLVs that 487 contain reachability information (such as types 135 and 236). Type 488 22 TLVs, however, MUST be flooded through this boundary, so that 489 every router in the network shares a common view of the topology. 491 Note that aggregation in a DC fabric can result in routing black 492 holes in some cases, and also possibly reduce the efficiency of 493 traffic engineering in the network. 495 7. OpenFabric Modifications to the IS-IS protocol 497 7.1. The Tier Level sub-TLV 499 A new sub-TLV is added to the type 22 TLV to indicate tier level, as 500 follows: 502 o sub-TLV number (one octet): TBA 504 o Tier identifier (one octet) 506 The tier identifier field contains the tier number of the local 507 router as calculated using the process above. If the tier number is 508 unknown, the sub-TLV MUST be included with a tier ID of 0xFF, which 509 indicates the advertising router does not have enough information to 510 calculate its tier number, or there is some error in calculating a 511 tier number. 513 7.2. The Do Not Reflood (DNR) address 515 Link state packets flooded to the DNR layer 2 (MAC) address TBA 516 SHOULD not be reflooded by receiving intermediate systems. 518 8. Security Considerations 520 This document outlines modifications to the IS-IS protocol for 521 operation on large scale data center fabrics. While it does add new 522 TLVs, and some local processing changes, it does not add any new 523 security vulnerabilities to the operation of IS-IS. However, 524 OpenFabric implementions SHOULD implement IS-IS cryptographic 525 authentication, as described in [RFC5304], and should enable other 526 security measures in accordance with best common practices for the 527 IS-IS protocol. 529 9. References 531 9.1. Normative References 533 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 534 Requirement Levels", BCP 14, RFC 2119, 535 DOI 10.17487/RFC2119, March 1997, 536 . 538 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 539 DOI 10.17487/RFC2629, June 1999, 540 . 542 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 543 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 544 October 2008, . 546 [RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way 547 Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, 548 DOI 10.17487/RFC5303, October 2008, 549 . 551 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 552 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 553 2008, . 555 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 556 DOI 10.17487/RFC5308, October 2008, 557 . 559 [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. 560 Shand, "Simplified Extension of Link State PDU (LSP) Space 561 for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, 562 . 564 9.2. Informative References 566 [I-D.ietf-isis-segment-routing-extensions] 567 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 568 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 569 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 570 segment-routing-extensions-11 (work in progress), March 571 2017. 573 [I-D.ietf-spring-segment-routing] 574 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 575 and R. Shakir, "Segment Routing Architecture", draft-ietf- 576 spring-segment-routing-11 (work in progress), February 577 2017. 579 [RFC3277] McPherson, D., "Intermediate System to Intermediate System 580 (IS-IS) Transient Blackhole Avoidance", RFC 3277, 581 DOI 10.17487/RFC3277, April 2002, 582 . 584 [RFC3719] Parker, J., Ed., "Recommendations for Interoperable 585 Networks using Intermediate System to Intermediate System 586 (IS-IS)", RFC 3719, DOI 10.17487/RFC3719, February 2004, 587 . 589 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 590 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 591 DOI 10.17487/RFC4271, January 2006, 592 . 594 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 595 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 596 2008, . 598 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 599 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 600 DOI 10.17487/RFC5440, March 2009, 601 . 603 [RFC5449] Baccelli, E., Jacquet, P., Nguyen, D., and T. Clausen, 604 "OSPF Multipoint Relay (MPR) Extension for Ad Hoc 605 Networks", RFC 5449, DOI 10.17487/RFC5449, February 2009, 606 . 608 [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) 609 Extension of OSPF Using Connected Dominating Set (CDS) 610 Flooding", RFC 5614, DOI 10.17487/RFC5614, August 2009, 611 . 613 [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 614 Originator Identification TLV for IS-IS", RFC 6232, 615 DOI 10.17487/RFC6232, May 2011, 616 . 618 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 619 Check Value and Timestamp TLV Definitions for Mobile Ad 620 Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182, 621 April 2014, . 623 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 624 Nadeau, "An Architecture for the Interface to the Routing 625 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 626 . 628 Authors' Addresses 630 Russ White 631 LinkedIn 633 Email: russ@riw.us 635 Shawn Zandi 636 LinkedIn 638 Email: szandi@linkedin.com 640 Nikos Triantafillis 641 LinkedIn 643 Email: ntriantafillis@gmail.com 645 Hannes Gredler 646 RtBrick Inc. 648 Email: hannes@rtbrick.com