idnits 2.17.1 draft-shen-isis-spine-leaf-ext-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 : ---------------------------------------------------------------------------- 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 (November 2, 2015) is 3088 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: May 5, 2016 November 2, 2015 7 IS-IS Routing for Spine-Leaf Topology 8 draft-shen-isis-spine-leaf-ext-00 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 May 5, 2016. 36 Copyright Notice 38 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . 9 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 73 7. Document Change Log . . . . . . . . . . . . . . . . . . . . . 10 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 8.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 The IS-IS routing protocol defined by [ISO10589] has been widely 82 deployed in provider networks, data centers and enterprise campus 83 environments. In the data center and enterprise switching networks, 84 Spine-Leaf topology is commonly used. This document describes the 85 mechanism where IS-IS routing can be optimized to take the advantage 86 of the unique Spine-Leaf topology. 88 When the network is in Spine-Leaf topology, normally a leaf node 89 connects to a number of spine nodes. Data traffic going from one 90 leaf node to another leaf node needs to pass through one of the spine 91 nodes. Also, the decision to choose one of the spine nodes is 92 usually part of the equal cost multi-path (ECMP) load sharing. The 93 spine nodes can be considered as gateway devices to reach the 94 destination leaf nodes. In this type of topologies, the spine nodes 95 have to know the topology and routing information of the entire 96 network, but the leaf nodes only need to know how to reach the 97 gateway devices which are the spine nodes they are uplinked to. 99 This document describes the IS-IS Spine-Leaf extension that allows 100 the spine nodes to have all the topology and routing information, 101 while keeping the leaf nodes free of topology information other than 102 the default gateway routing information. The leaf nodes do not even 103 need to run their Shortest Path First (SPF) since there is no network 104 topology to run for. 106 1.1. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. Motivations 114 o The leaf nodes in Spine-Leaf topology do not benefit much to have 115 the complete topology and routing information of the entire domain 116 while the forwarding actions are only to use ECMP with spine nodes 117 as nexthops. 119 o The spine nodes in Spine-Leaf topology are richly connected to 120 leaf nodes, and they need to flood every Link State PDUs (LSPs) to 121 all the leaf nodes. It saves the spine nodes' CPU and link 122 bandwidth resources if the flooding is blocked to those leaf 123 nodes. 125 o During the time a spine node has a network problem, every leaf 126 node connected to it will generate its LSP update to report the 127 problem to all the other spine nodes, and those spine nodes will 128 further flood them to all the leaf nodes, causing a O(n^2) 129 flooding storm unnecessarily since every leaf node already knows 130 that spine node having problem. 132 o Small devices and appliances of Internet of Things (IoT) can be 133 considered as leafs in the routing topology sense. They have CPU 134 and memory constrains in design, and those IoT devices do not have 135 to know the exact network topology and prefixes as long as there 136 are ways to reach the cloud servers or other devices and they want 137 to be part of the dynamic routing. 139 3. Spine-Leaf (SL) Extension 140 3.1. Topology Example 142 +--------+ +--------+ +--------+ 143 | | | | | | 144 | Spine1 +----+ Spine2 +- ......... -+ SpineN | 145 | | | | | | 146 +-+-+-+-++ ++-+-+-+-+ +-+-+-+-++ 147 +------+ | | | | | | | | | | | 148 | +-----|-|-|------+ | | | | | | | 149 | | +--|-|-|--------+-|-|-----------------+ | | | 150 | | | | | | +---+ | | | | | 151 | | | | | | | +--|-|-------------------+ | | 152 | | | | | | | | | | +------+ +----+ 153 | | | | | | | | | +--------------|----------+ | 154 | | | | | | | | +-------------+ | | | 155 | | | | | +----|--|----------------|--|--------+ | | 156 | | | | +------|--|--------------+ | | | | | 157 | | | +------+ | | | | | | | | 158 ++--+--++ +-+-+--++ ++-+--+-+ ++-+--+-+ 159 | Leaf1 +~~~~~~+ Leaf2 | ........ | LeafX | | LeafY | 160 +-------+ +-------+ +-------+ +-------+ 162 Figure 1: A Spine-Leaf Topology 164 3.2. Applicability Statement 166 This extension assumes the network is a basic Spine-Leaf topology, 167 and it will not work in an arbitrary network setup. The spine nodes 168 can be viewed as the aggregation layer of the network, and the leaf 169 nodes as the access layer of the network. The leaf nodes use load 170 sharing algorithm with spine nodes as nexthops in routing and 171 forwarding. 173 This extension assumes the spine nodes are inter-connected. Spine 174 nodes exchanges normal IS-IS topology and routing information among 175 themselves. This extension does not apply in the case where spine 176 nodes only have links to leaf nodes but not to themselves. 178 Although the example diagram in Figure 1 shows a fully meshed Spine- 179 Leaf topology, but this extension also works in the case where they 180 are partially meshed. For instance, the leaf1 through leaf10 are 181 fully meshed with spine1 through spine5; and leaf11 through leaf20 182 are fully meshed with spine4 through spine8, and all the spines are 183 inter-connected in a redundant fashion. 185 This extension also works with the topology with more than the 186 typical two layers of spine and leaf. For instance, in example 187 diagram Figure 1, there can be another Core layer of routers/switches 188 on top of the aggregation layer. From an IS-IS routing point of 189 view, the Core nodes are not affected by this extension and will have 190 the complete topology and routing information just like the spine 191 nodes. To make the network even more scalable, the Core layer can be 192 run at the level-2 IS-IS domain while the Spine layer and the Leaf 193 layer staying at the level-1 IS-IS domain. 195 This extension also supports the leaf nodes having local connections 196 to other leaf nodes, in the example diagram Figure 1 there is a 197 connection between 'Leaf1' node and 'Leaf2' node, and an external 198 host can be dual homed into both of the leaf nodes. 200 This extension assumes the link between the spine and leaf nodes are 201 point-to-point, or point-to-point over LAN [RFC5309]. The links 202 connecting the spine nodes, or the links between the leaf nodes can 203 be any type. 205 3.3. Extension Encoding 207 This extension introduces one TLV for IS-IS Hello (IIH) PDU and it is 208 used by both spine and leaf nodes in the Spine-Leaf mechanism. 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Type | Length | SL Flag | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Default Route Metric | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | .. Optional Sub-TLVs 218 +-+-+-+-+-+-+-+-+-.... 220 The fields of this TLV are defined as follows: 222 Type: TBD. 8 bits value, suggested value 150. 224 Length: Variable. 8 bits value. The mandatory part is 6 octets. 226 SL Flag: 16 bits value field of following flags: 228 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Reserved |B|R|L| 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 L bit (0x01): Only leaf node sets this bit. If the L bit is 233 set in the SL flag, the node indicates it is in 'Leaf- 234 Mode'. 236 R bit (0x02): Only Spine node sets this bit. If the R bit is 237 set, the node indicates to the leaf neighbor that it 238 can be used as the default route gateway. 240 B bit (0x04): Only leaf node sets this bit on Leaf-Leaf link, 241 in additional to the 'L' bit setting. If the B bit is 242 set, the node indicates to its leaf neighbor that it 243 can be used as the backup default route gateway. It 244 will also sets high 'Default Route Metric' value. 246 Default Route Metric: Normal only spine nodes set this default 247 route metric. This default route metric is for all the 248 address families and IS-IS topologies. A leaf node 249 SHOULD add this metric on top of the outbound interface 250 IS-IS metric towards the spine node when installing the 251 default route. In the case where the leaf node sets the 252 'B' bit in SL-flag on the Leaf-Leaf link, this 'Default 253 Route Metric' SHOULD be set to very high for the neighbor 254 leaf node to use it as the backup gateway. 256 Optional Sub-TLV: Not defined in this document, for future 257 extension on SL. 259 3.4. Mechanism 261 Each leaf node is provisioned by network operators as in IS-IS 'Leaf- 262 Mode'. A spine node does not need explicit configuration. A leaf 263 node inserts the Spine-Leaf TLV and sets the 'L' bit in the SL flag 264 field when sending out its IIH PDU over all its links. 266 The spine node when receiving the IIH with the SL TLV and 'L' bit 267 set, it labels the point-to-point interface and adjacency to be a 268 'Leaf-Peer'. When the spine node sending out IIH PDU to the 'Leaf- 269 Peer', it will also insert the Spine-Leaf TLV and set the 'R' bit in 270 the SL flag field. This 'R' bit indicates to the 'Leaf-Peer' 271 neighbor that the spine node can be used as a default routing 272 nexthop. 274 There is no change to the IS-IS adjacency bring-up mechanism for the 275 point-to-point interface. 277 For the spine node with 'Leaf-Peer' adjacencies, the IS-IS LSP 278 flooding is blocked to the 'Leaf-Peer' interface, except for the LSP 279 PDUs in which the IS-IS System-ID matches the System-ID of the 'Leaf- 280 Peer' adjacency. This exception is needed since when the leaf node 281 reboots, the spine node needs to forward to the leaf node its 282 previous generation of LSP. No other LSP PDU needs to be flooded 283 over this 'Leaf-Peer' interface. 285 The leaf node will perform IS-IS LSP flooding as normal over all of 286 its IS-IS adjacencies, this means the leaf node will flood its own 287 LSPs over to spine nodes since those are all the LSPs in its LSP 288 database. 290 The spine node will receive all the LSP PDUs in the network, 291 including all the spine nodes and leaf nodes. It will perform 292 Shortest Path First (SPF) as normal IS-IS node does. There is no 293 change to the route calculation and forwarding on the spine nodes. 295 But the leaf node does not have any LSP in the network except for its 296 own, and there is no need to perform SPF algorithm on the system. It 297 only needs to download the default route with the nexthops of those 298 'Spine-Peer' which has the 'R' bit set in the Spine-Leaf TLV in IIH 299 PDUs. IS-IS can perform equal cost or unequal cost load sharing 300 while using the spine nodes as nexthops. The aggregated metric of 301 the outbound interface and the 'Default Route Metric' in the Spine- 302 Leaf TLV can be used for this purpose. 304 In summary, this extension requires leaf node to insert Spine-Leaf 305 TLV in IIH, and set the 'L' bit in the SL flag, and download IS-IS 306 default route using the spine nodes as nexthops where the 'Spine- 307 Peer' set the 'R' bit in its IIH PDU; It requires spine node to 308 respond from 'Leaf-Peer' by inserting Spine-Leaf TLV in its IIH, 309 setting the 'R' bit in the SL flag, and blocking the LSP flooding 310 with the exception that it will set SRMflag on the LSPs that belong 311 to the 'Leaf-Peer' over that interface. 313 3.5. Implementation and Operation 315 3.5.1. CSNP PDU 317 In Spine-Leaf extension, Complete Sequence Number PDU (CSNP) does not 318 need to be transmitted over the Spine-Leaf link. Some IS-IS 319 implementation sends CSNPs after the initial adjacency bring-up over 320 point-to-point interface. There is no need for this optimization 321 here since the Leaf does not need to receive any other LSPs from the 322 network, and the only LSPs transmitted across the Spine-Leaf link is 323 the leaf node LSP. 325 Also in the graceful restart case[RFC5306], for the same reason, 326 there is no need to send the CSNPs over the Spine-Leaf interface. It 327 only needs to set the SRMflag on the LSPs belonging to the 'Leaf- 328 Peer' on the spine node, and set the SRMflag on its own LSPs on the 329 leaf node. 331 3.5.2. Leaf to Leaf connection 333 Leaf to leaf node links are useful in host redundancy cases in 334 switching networks, and normally there is no special requirement of 335 mechanism is needed for this case. Each leaf node will set the 'L' 336 bit in its IIH of the Spine-Leaf flag. LSP will be exchanged over 337 this link. In the example diagram Figure 1, the Leaf1 will get 338 Leaf2's LSP and Leaf2 will get Leaf1's LSP. They will install more 339 specific routes towards each other using this local Leaf-Leaf link. 340 SPF will be performed in this case just like when the entire network 341 only involves with those two IS-IS nodes. This does not affect the 342 normal Spine-Leaf mechanism they perform toward the spine nodes. 344 Besides the local leaf-to-leaf traffic, the leaf node can serve as a 345 backup gateway for its leaf neighbor. It needs to remove the 346 'Overload-Bit' setting in its LSP, and it sets both the 'L' bit and 347 the 'B' bit in the SL-flag with a high 'Default Route Metric' value. 349 3.5.3. Overload Bit 351 The leaf node SHOULD set the 'overload' bit on its LSP PDU, since if 352 the spine nodes were to forward traffic not meant for the local node, 353 the leaf node does not have the topology information to prevent a 354 routing/forwarding loop. 356 3.5.4. Spine Node Hostname 358 This extension creates a non-reciprocal relationship between the 359 spine node and leaf node. The spine node will receive leaf's LSP and 360 will know the leaf's hostname, but the leaf does not have spine's 361 LSP. This extension allows the Dynamic Hostname TLV [RFC5301] to be 362 optionally included in spine's IIH PDU when sending to a 'Leaf-Peer'. 363 This is useful in troubleshooting cases. 365 3.5.5. Default Route Metric 367 This metric is part of the aggregated metric for leaf's default route 368 installation with load sharing among the spine nodes. When a spine 369 node is in 'overload' condition, it should set this metric to maximum 370 to discourage the leaf using it as part of the loadsharing. 372 In some cases, certain spine nodes may have less bandwidth in link 373 provisioning or in real-time condition, and it can use this metric to 374 signal to the leaf nodes dynamically. 376 In other cases, such as when the spine node loses a link to a 377 particular leaf node, although it can redirect the traffic to other 378 spine nodes to reach that destination leaf node, but it MAY want to 379 increase this metric value if the inter-spine connection becomes over 380 utilized, or the latency becomes an issue. 382 In the leaf-leaf link as a backup gateway use case, the 'Default 383 Route Metric' SHOULD always be set to very high value. 385 3.5.6. Other End-to-End Services 387 Losing the topology information will have an impact on some of the 388 end-to-end network services, for instance, MPLS TE or end-to-end 389 segment routing. Some other mechanisms such as those described in 390 PCE [RFC4655] based solution may be used. In this Spine-Leaf 391 extension, the role of the leaf node is not too much different from 392 the multi-level IS-IS routing while the level-1 IS-IS nodes only have 393 the default route information towards the node which has the Attach 394 Bit (ATT) set, and the level-2 backbone does not have any topology 395 information of the level-1 areas. The exact mechanism to enable 396 certain end-to-end network services in Spine-Leaf network is outside 397 the scope of this document. 399 3.5.7. Address Family and Topology 401 IPv6 Address families[RFC5308], Multi-Topology (MT)[RFC5120] and 402 Multi-Instance (MI)[RFC6822] information is carried over the IIH PDU. 403 Since the goal is to simplify the operation of IS-IS network, for the 404 simplicity of this extension, the Spine-Leaf mechanism is applied the 405 same way to all the address families, MTs and MIs. 407 3.5.8. Migration 409 For this extension to be deployed in existing networks, a simple 410 migration scheme is needed. To support any leaf node in the network, 411 all the involved spine nodes have to be upgraded first. So the first 412 step is to migrate all the involved spine nodes to support this 413 extension, then the leaf nodes can be enabled with 'Leaf-Mode' one by 414 one. No flag day is needed for the extension migration. 416 4. IANA Considerations 418 A new TLV codepoint is defined in this document and needs to be 419 assigned by IANA from the "IS-IS TLV Codepoints" registry. It is 420 referred to as the Spine-Leaf TLV and the suggested value is 150. 421 This TLV is only to be optionally inserted in the IIH PDU. This 422 document does not propose any sub-TLV out of this Spine-Leaf TLV. 424 IANA is also requested to maintain the SL-flag bit values in this 425 TLV, and 0x01, 0x02 and 0x04 bits are defined in this document. 427 Value Name IIH LSP SNP Purge 428 ----- --------------------- --- --- --- ----- 429 150 Spine-Leaf y n n n 431 This extension also proposes to have the Dynamic Hostname TLV, 432 already assigned as code 137, to be allowed in IIH PDU. 434 Value Name IIH LSP SNP Purge 435 ----- --------------------- --- --- --- ----- 436 137 Dynamic Name y y n y 438 5. Security Considerations 440 Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], 441 [RFC5310], and [RFC7602]. This extension does not raise additional 442 security issues. 444 6. Acknowledgments 446 TBD. 448 7. Document Change Log 450 o Initial version of the draft is published in November 2015. 452 8. References 454 8.1. Normative References 456 [ISO10589] 457 ISO "International Organization for Standardization", 458 "Intermediate system to Intermediate system intra-domain 459 routeing information exchange protocol for use in 460 conjunction with the protocol for providing the 461 connectionless-mode Network Service (ISO 8473), ISO/IEC 462 10589:2002, Second Edition.", Nov 2002. 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, 466 DOI 10.17487/RFC2119, March 1997, 467 . 469 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 470 Topology (MT) Routing in Intermediate System to 471 Intermediate Systems (IS-ISs)", RFC 5120, 472 DOI 10.17487/RFC5120, February 2008, 473 . 475 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 476 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 477 October 2008, . 479 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 480 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 481 2008, . 483 [RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", 484 RFC 5306, DOI 10.17487/RFC5306, October 2008, 485 . 487 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 488 DOI 10.17487/RFC5308, October 2008, 489 . 491 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 492 and M. Fanto, "IS-IS Generic Cryptographic 493 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 494 2009, . 496 [RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D. 497 Ward, "IS-IS Multi-Instance", RFC 6822, 498 DOI 10.17487/RFC6822, December 2012, 499 . 501 [RFC7602] Chunduri, U., Lu, W., Tian, A., and N. Shen, "IS-IS 502 Extended Sequence Number TLV", RFC 7602, 503 DOI 10.17487/RFC7602, July 2015, 504 . 506 8.2. Informative References 508 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 509 Element (PCE)-Based Architecture", RFC 4655, 510 DOI 10.17487/RFC4655, August 2006, 511 . 513 [RFC5309] Shen, N., Ed. and A. Zinin, Ed., "Point-to-Point Operation 514 over LAN in Link State Routing Protocols", RFC 5309, 515 DOI 10.17487/RFC5309, October 2008, 516 . 518 Authors' Addresses 520 Naiming Shen 521 Cisco Systems 522 560 McCarthy Blvd. 523 Milpitas, CA 95035 524 US 526 Email: naiming@cisco.com 528 Sanjay Thyamagundalu 529 Cisco Systems 530 3625 Cisco Way 531 San Jose, CA 95134 532 US 534 Email: sanjayt@cisco.com