idnits 2.17.1 draft-shen-isis-spine-leaf-ext-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 25, 2016) is 2917 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' ** Obsolete normative reference: RFC 5306 (Obsoleted by RFC 8706) ** Obsolete normative reference: RFC 6822 (Obsoleted by RFC 8202) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group N. Shen 3 Internet-Draft S. Thyamagundalu 4 Intended status: Standards Track Cisco Systems 5 Expires: October 27, 2016 April 25, 2016 7 IS-IS Routing for Spine-Leaf Topology 8 draft-shen-isis-spine-leaf-ext-01 10 Abstract 12 This document describes a mechanism for routers and switches in 13 Spine-Leaf type topology to have non-reciprocal Intermediate System 14 to Intermediate System (IS-IS) routing relationships between the 15 leafs and spines. The leaf nodes do not need to have the topology 16 information of other nodes and exact prefixes in the network. This 17 extension also has application in the Internet of Things (IoT). 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 27, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Spine-Leaf (SL) Extension . . . . . . . . . . . . . . . . . . 4 57 3.1. Topology Example . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Applicability Statement . . . . . . . . . . . . . . . . . 4 59 3.3. Extension Encoding . . . . . . . . . . . . . . . . . . . 5 60 3.4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.5. Implementation and Operation . . . . . . . . . . . . . . 7 62 3.5.1. CSNP PDU . . . . . . . . . . . . . . . . . . . . . . 7 63 3.5.2. Leaf to Leaf connection . . . . . . . . . . . . . . . 8 64 3.5.3. Overload Bit . . . . . . . . . . . . . . . . . . . . 8 65 3.5.4. Spine Node Hostname . . . . . . . . . . . . . . . . . 8 66 3.5.5. Default Route Metric . . . . . . . . . . . . . . . . 8 67 3.5.6. Other End-to-End Services . . . . . . . . . . . . . . 9 68 3.5.7. Address Family and Topology . . . . . . . . . . . . . 9 69 3.5.8. Migration . . . . . . . . . . . . . . . . . . . . . . 9 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 73 7. Document Change Log . . . . . . . . . . . . . . . . . . . . . 10 74 7.1. Changes to draft-shen-isis-spine-leaf-ext-01.txt . . . . 10 75 7.2. Changes to draft-shen-isis-spine-leaf-ext-00.txt . . . . 10 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 78 8.2. Informative References . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 The IS-IS routing protocol defined by [ISO10589] has been widely 84 deployed in provider networks, data centers and enterprise campus 85 environments. In the data center and enterprise switching networks, 86 Spine-Leaf topology is commonly used. This document describes the 87 mechanism where IS-IS routing can be optimized to take the advantage 88 of the unique Spine-Leaf topology. 90 When the network is in Spine-Leaf topology, normally a leaf node 91 connects to a number of spine nodes. Data traffic going from one 92 leaf node to another leaf node needs to pass through one of the spine 93 nodes. Also, the decision to choose one of the spine nodes is 94 usually part of the equal cost multi-path (ECMP) load sharing. The 95 spine nodes can be considered as gateway devices to reach the 96 destination leaf nodes. In this type of topologies, the spine nodes 97 have to know the topology and routing information of the entire 98 network, but the leaf nodes only need to know how to reach the 99 gateway devices which are the spine nodes they are uplinked to. 101 This document describes the IS-IS Spine-Leaf extension that allows 102 the spine nodes to have all the topology and routing information, 103 while keeping the leaf nodes free of topology information other than 104 the default gateway routing information. The leaf nodes do not even 105 need to run their Shortest Path First (SPF) since there is no network 106 topology to run for. 108 1.1. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 2. Motivations 116 o The leaf nodes in Spine-Leaf topology do not benefit much to have 117 the complete topology and routing information of the entire domain 118 while the forwarding actions are only to use ECMP with spine nodes 119 as nexthops. 121 o The spine nodes in Spine-Leaf topology are richly connected to 122 leaf nodes, and they need to flood every Link State PDUs (LSPs) to 123 all the leaf nodes. It saves the spine nodes' CPU and link 124 bandwidth resources if the flooding is blocked to those leaf 125 nodes. 127 o During the time a spine node has a network problem, every leaf 128 node connected to it will generate its LSP update to report the 129 problem to all the other spine nodes, and those spine nodes will 130 further flood them to all the leaf nodes, causing a O(n^2) 131 flooding storm unnecessarily since every leaf node already knows 132 that spine node having problem. 134 o Small devices and appliances of Internet of Things (IoT) can be 135 considered as leafs in the routing topology sense. They have CPU 136 and memory constrains in design, and those IoT devices do not have 137 to know the exact network topology and prefixes as long as there 138 are ways to reach the cloud servers or other devices and they want 139 to be part of the dynamic routing. 141 3. Spine-Leaf (SL) Extension 143 3.1. Topology Example 145 +--------+ +--------+ +--------+ 146 | | | | | | 147 | Spine1 +----+ Spine2 +- ......... -+ SpineN | 148 | | | | | | 149 +-+-+-+-++ ++-+-+-+-+ +-+-+-+-++ 150 +------+ | | | | | | | | | | | 151 | +-----|-|-|------+ | | | | | | | 152 | | +--|-|-|--------+-|-|-----------------+ | | | 153 | | | | | | +---+ | | | | | 154 | | | | | | | +--|-|-------------------+ | | 155 | | | | | | | | | | +------+ +----+ 156 | | | | | | | | | +--------------|----------+ | 157 | | | | | | | | +-------------+ | | | 158 | | | | | +----|--|----------------|--|--------+ | | 159 | | | | +------|--|--------------+ | | | | | 160 | | | +------+ | | | | | | | | 161 ++--+--++ +-+-+--++ ++-+--+-+ ++-+--+-+ 162 | Leaf1 +~~~~~~+ Leaf2 | ........ | LeafX | | LeafY | 163 +-------+ +-------+ +-------+ +-------+ 165 Figure 1: A Spine-Leaf Topology 167 3.2. Applicability Statement 169 This extension assumes the network is a basic Spine-Leaf topology, 170 and it will not work in an arbitrary network setup. The spine nodes 171 can be viewed as the aggregation layer of the network, and the leaf 172 nodes as the access layer of the network. The leaf nodes use load 173 sharing algorithm with spine nodes as nexthops in routing and 174 forwarding. 176 This extension assumes the spine nodes are inter-connected. Spine 177 nodes exchanges normal IS-IS topology and routing information among 178 themselves. This extension does not apply in the case where spine 179 nodes only have links to leaf nodes but not to themselves. 181 Although the example diagram in Figure 1 shows a fully meshed Spine- 182 Leaf topology, but this extension also works in the case where they 183 are partially meshed. For instance, the leaf1 through leaf10 are 184 fully meshed with spine1 through spine5; and leaf11 through leaf20 185 are fully meshed with spine4 through spine8, and all the spines are 186 inter-connected in a redundant fashion. 188 This extension also works with the topology with more than the 189 typical two layers of spine and leaf. For instance, in example 190 diagram Figure 1, there can be another Core layer of routers/switches 191 on top of the aggregation layer. From an IS-IS routing point of 192 view, the Core nodes are not affected by this extension and will have 193 the complete topology and routing information just like the spine 194 nodes. To make the network even more scalable, the Core layer can be 195 run at the level-2 IS-IS domain while the Spine layer and the Leaf 196 layer staying at the level-1 IS-IS domain. 198 This extension also supports the leaf nodes having local connections 199 to other leaf nodes, in the example diagram Figure 1 there is a 200 connection between 'Leaf1' node and 'Leaf2' node, and an external 201 host can be dual homed into both of the leaf nodes. 203 This extension assumes the link between the spine and leaf nodes are 204 point-to-point, or point-to-point over LAN [RFC5309]. The links 205 connecting the spine nodes, or the links between the leaf nodes can 206 be any type. 208 3.3. Extension Encoding 210 This extension introduces one TLV for IS-IS Hello (IIH) PDU and it is 211 used by both spine and leaf nodes in the Spine-Leaf mechanism. 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Type | Length | SL Flag | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Default Route Metric | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | .. Optional Sub-TLVs 221 +-+-+-+-+-+-+-+-+-.... 223 The fields of this TLV are defined as follows: 225 Type: TBD. 8 bits value, suggested value 150. 227 Length: Variable. 8 bits value. The mandatory part is 6 octets. 229 SL Flag: 16 bits value field of following flags: 231 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Reserved |B|R|L| 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 L bit (0x01): Only leaf node sets this bit. If the L bit is 237 set in the SL flag, the node indicates it is in 'Leaf- 238 Mode'. 240 R bit (0x02): Only Spine node sets this bit. If the R bit is 241 set, the node indicates to the leaf neighbor that it 242 can be used as the default route gateway. 244 B bit (0x04): Only leaf node sets this bit on Leaf-Leaf link, 245 in additional to the 'L' bit setting. If the B bit is 246 set, the node indicates to its leaf neighbor that it 247 can be used as the backup default route gateway. It 248 will also sets high 'Default Route Metric' value. 250 Default Route Metric: Normal only spine nodes set this default 251 route metric. This default route metric is for all the 252 address families and IS-IS topologies. A leaf node 253 SHOULD add this metric on top of the outbound interface 254 IS-IS metric towards the spine node when installing the 255 default route. In the case where the leaf node sets the 256 'B' bit in SL-flag on the Leaf-Leaf link, this 'Default 257 Route Metric' SHOULD be set to very high for the neighbor 258 leaf node to use it as the backup gateway. 260 Optional Sub-TLV: Not defined in this document, for future 261 extension on SL. 263 3.4. Mechanism 265 Each leaf node is provisioned by network operators as in IS-IS 'Leaf- 266 Mode'. A spine node does not need explicit configuration. A leaf 267 node inserts the Spine-Leaf TLV and sets the 'L' bit in the SL flag 268 field when sending out its IIH PDU over all its links. 270 The spine node when receiving the IIH with the SL TLV and 'L' bit 271 set, it labels the point-to-point interface and adjacency to be a 272 'Leaf-Peer'. When the spine node sending out IIH PDU to the 'Leaf- 273 Peer', it will also insert the Spine-Leaf TLV and set the 'R' bit in 274 the SL flag field. This 'R' bit indicates to the 'Leaf-Peer' 275 neighbor that the spine node can be used as a default routing 276 nexthop. 278 There is no change to the IS-IS adjacency bring-up mechanism for the 279 point-to-point interface. 281 For the spine node with 'Leaf-Peer' adjacencies, the IS-IS LSP 282 flooding is blocked to the 'Leaf-Peer' interface, except for the LSP 283 PDUs in which the IS-IS System-ID matches the System-ID of the 'Leaf- 284 Peer' adjacency. This exception is needed since when the leaf node 285 reboots, the spine node needs to forward to the leaf node its 286 previous generation of LSP. No other LSP PDU needs to be flooded 287 over this 'Leaf-Peer' interface. 289 The leaf node will perform IS-IS LSP flooding as normal over all of 290 its IS-IS adjacencies, this means the leaf node will flood its own 291 LSPs over to spine nodes since those are all the LSPs in its LSP 292 database. 294 The spine node will receive all the LSP PDUs in the network, 295 including all the spine nodes and leaf nodes. It will perform 296 Shortest Path First (SPF) as normal IS-IS node does. There is no 297 change to the route calculation and forwarding on the spine nodes. 299 But the leaf node does not have any LSP in the network except for its 300 own, and there is no need to perform SPF algorithm on the system. It 301 only needs to download the default route with the nexthops of those 302 'Spine-Peer' which has the 'R' bit set in the Spine-Leaf TLV in IIH 303 PDUs. IS-IS can perform equal cost or unequal cost load sharing 304 while using the spine nodes as nexthops. The aggregated metric of 305 the outbound interface and the 'Default Route Metric' in the Spine- 306 Leaf TLV can be used for this purpose. 308 In summary, this extension requires leaf node to insert Spine-Leaf 309 TLV in IIH, and set the 'L' bit in the SL flag, and download IS-IS 310 default route using the spine nodes as nexthops where the 'Spine- 311 Peer' set the 'R' bit in its IIH PDU; It requires spine node to 312 respond from 'Leaf-Peer' by inserting Spine-Leaf TLV in its IIH, 313 setting the 'R' bit in the SL flag, and blocking the LSP flooding 314 with the exception that it will set SRMflag on the LSPs that belong 315 to the 'Leaf-Peer' over that interface. 317 3.5. Implementation and Operation 319 3.5.1. CSNP PDU 321 In Spine-Leaf extension, Complete Sequence Number PDU (CSNP) does not 322 need to be transmitted over the Spine-Leaf link. Some IS-IS 323 implementation sends CSNPs after the initial adjacency bring-up over 324 point-to-point interface. There is no need for this optimization 325 here since the Leaf does not need to receive any other LSPs from the 326 network, and the only LSPs transmitted across the Spine-Leaf link is 327 the leaf node LSP. 329 Also in the graceful restart case[RFC5306], for the same reason, 330 there is no need to send the CSNPs over the Spine-Leaf interface. It 331 only needs to set the SRMflag on the LSPs belonging to the 'Leaf- 332 Peer' on the spine node, and set the SRMflag on its own LSPs on the 333 leaf node. 335 3.5.2. Leaf to Leaf connection 337 Leaf to leaf node links are useful in host redundancy cases in 338 switching networks, and normally there is no special requirement of 339 mechanism is needed for this case. Each leaf node will set the 'L' 340 bit in its IIH of the Spine-Leaf flag. LSP will be exchanged over 341 this link. In the example diagram Figure 1, the Leaf1 will get 342 Leaf2's LSP and Leaf2 will get Leaf1's LSP. They will install more 343 specific routes towards each other using this local Leaf-Leaf link. 344 SPF will be performed in this case just like when the entire network 345 only involves with those two IS-IS nodes. This does not affect the 346 normal Spine-Leaf mechanism they perform toward the spine nodes. 348 Besides the local leaf-to-leaf traffic, the leaf node can serve as a 349 backup gateway for its leaf neighbor. It needs to remove the 350 'Overload-Bit' setting in its LSP, and it sets both the 'L' bit and 351 the 'B' bit in the SL-flag with a high 'Default Route Metric' value. 353 3.5.3. Overload Bit 355 The leaf node SHOULD set the 'overload' bit on its LSP PDU, since if 356 the spine nodes were to forward traffic not meant for the local node, 357 the leaf node does not have the topology information to prevent a 358 routing/forwarding loop. 360 3.5.4. Spine Node Hostname 362 This extension creates a non-reciprocal relationship between the 363 spine node and leaf node. The spine node will receive leaf's LSP and 364 will know the leaf's hostname, but the leaf does not have spine's 365 LSP. This extension allows the Dynamic Hostname TLV [RFC5301] to be 366 optionally included in spine's IIH PDU when sending to a 'Leaf-Peer'. 367 This is useful in troubleshooting cases. 369 3.5.5. Default Route Metric 371 This metric is part of the aggregated metric for leaf's default route 372 installation with load sharing among the spine nodes. When a spine 373 node is in 'overload' condition, it should set this metric to maximum 374 to discourage the leaf using it as part of the loadsharing. 376 In some cases, certain spine nodes may have less bandwidth in link 377 provisioning or in real-time condition, and it can use this metric to 378 signal to the leaf nodes dynamically. 380 In other cases, such as when the spine node loses a link to a 381 particular leaf node, although it can redirect the traffic to other 382 spine nodes to reach that destination leaf node, but it MAY want to 383 increase this metric value if the inter-spine connection becomes over 384 utilized, or the latency becomes an issue. 386 In the leaf-leaf link as a backup gateway use case, the 'Default 387 Route Metric' SHOULD always be set to very high value. 389 3.5.6. Other End-to-End Services 391 Losing the topology information will have an impact on some of the 392 end-to-end network services, for instance, MPLS TE or end-to-end 393 segment routing. Some other mechanisms such as those described in 394 PCE [RFC4655] based solution may be used. In this Spine-Leaf 395 extension, the role of the leaf node is not too much different from 396 the multi-level IS-IS routing while the level-1 IS-IS nodes only have 397 the default route information towards the node which has the Attach 398 Bit (ATT) set, and the level-2 backbone does not have any topology 399 information of the level-1 areas. The exact mechanism to enable 400 certain end-to-end network services in Spine-Leaf network is outside 401 the scope of this document. 403 3.5.7. Address Family and Topology 405 IPv6 Address families[RFC5308], Multi-Topology (MT)[RFC5120] and 406 Multi-Instance (MI)[RFC6822] information is carried over the IIH PDU. 407 Since the goal is to simplify the operation of IS-IS network, for the 408 simplicity of this extension, the Spine-Leaf mechanism is applied the 409 same way to all the address families, MTs and MIs. 411 3.5.8. Migration 413 For this extension to be deployed in existing networks, a simple 414 migration scheme is needed. To support any leaf node in the network, 415 all the involved spine nodes have to be upgraded first. So the first 416 step is to migrate all the involved spine nodes to support this 417 extension, then the leaf nodes can be enabled with 'Leaf-Mode' one by 418 one. No flag day is needed for the extension migration. 420 4. IANA Considerations 422 A new TLV codepoint is defined in this document and needs to be 423 assigned by IANA from the "IS-IS TLV Codepoints" registry. It is 424 referred to as the Spine-Leaf TLV and the suggested value is 150. 425 This TLV is only to be optionally inserted in the IIH PDU. This 426 document does not propose any sub-TLV out of this Spine-Leaf TLV. 427 IANA is also requested to maintain the SL-flag bit values in this 428 TLV, and 0x01, 0x02 and 0x04 bits are defined in this document. 430 Value Name IIH LSP SNP Purge 431 ----- --------------------- --- --- --- ----- 432 150 Spine-Leaf y n n n 434 This extension also proposes to have the Dynamic Hostname TLV, 435 already assigned as code 137, to be allowed in IIH PDU. 437 Value Name IIH LSP SNP Purge 438 ----- --------------------- --- --- --- ----- 439 137 Dynamic Name y y n y 441 5. Security Considerations 443 Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], 444 [RFC5310], and [RFC7602]. This extension does not raise additional 445 security issues. 447 6. Acknowledgments 449 TBD. 451 7. Document Change Log 453 7.1. Changes to draft-shen-isis-spine-leaf-ext-01.txt 455 o Submitted April 2016. 457 o No change. Refresh the draft version. 459 7.2. Changes to draft-shen-isis-spine-leaf-ext-00.txt 461 o Initial version of the draft is published in November 2015. 463 8. References 464 8.1. Normative References 466 [ISO10589] 467 ISO "International Organization for Standardization", 468 "Intermediate system to Intermediate system intra-domain 469 routeing information exchange protocol for use in 470 conjunction with the protocol for providing the 471 connectionless-mode Network Service (ISO 8473), ISO/IEC 472 10589:2002, Second Edition.", Nov 2002. 474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 475 Requirement Levels", BCP 14, RFC 2119, 476 DOI 10.17487/RFC2119, March 1997, 477 . 479 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 480 Topology (MT) Routing in Intermediate System to 481 Intermediate Systems (IS-ISs)", RFC 5120, 482 DOI 10.17487/RFC5120, February 2008, 483 . 485 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 486 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 487 October 2008, . 489 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 490 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 491 2008, . 493 [RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", 494 RFC 5306, DOI 10.17487/RFC5306, October 2008, 495 . 497 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 498 DOI 10.17487/RFC5308, October 2008, 499 . 501 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 502 and M. Fanto, "IS-IS Generic Cryptographic 503 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 504 2009, . 506 [RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D. 507 Ward, "IS-IS Multi-Instance", RFC 6822, 508 DOI 10.17487/RFC6822, December 2012, 509 . 511 [RFC7602] Chunduri, U., Lu, W., Tian, A., and N. Shen, "IS-IS 512 Extended Sequence Number TLV", RFC 7602, 513 DOI 10.17487/RFC7602, July 2015, 514 . 516 8.2. Informative References 518 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 519 Element (PCE)-Based Architecture", RFC 4655, 520 DOI 10.17487/RFC4655, August 2006, 521 . 523 [RFC5309] Shen, N., Ed. and A. Zinin, Ed., "Point-to-Point Operation 524 over LAN in Link State Routing Protocols", RFC 5309, 525 DOI 10.17487/RFC5309, October 2008, 526 . 528 Authors' Addresses 530 Naiming Shen 531 Cisco Systems 532 560 McCarthy Blvd. 533 Milpitas, CA 95035 534 US 536 Email: naiming@cisco.com 538 Sanjay Thyamagundalu 539 Cisco Systems 540 3625 Cisco Way 541 San Jose, CA 95134 542 US 544 Email: sanjayt@cisco.com