idnits 2.17.1 draft-white-distoptflood-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 3, 2020) is 1482 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ISO10589' is defined on line 284, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 292, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 297, but no explicit reference was found in the text == Unused Reference: 'RFC5120' is defined on line 301, but no explicit reference was found in the text == Unused Reference: 'RFC5301' is defined on line 307, but no explicit reference was found in the text == Unused Reference: 'RFC5303' is defined on line 311, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 316, but no explicit reference was found in the text == Unused Reference: 'RFC5308' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'RFC5309' is defined on line 324, but no explicit reference was found in the text == Unused Reference: 'RFC5311' is defined on line 329, but no explicit reference was found in the text == Unused Reference: 'RFC5316' is defined on line 334, but no explicit reference was found in the text == Unused Reference: 'RFC7981' is defined on line 344, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-isis-segment-routing-extensions' is defined on line 355, but no explicit reference was found in the text == Unused Reference: 'RFC3277' is defined on line 361, but no explicit reference was found in the text == Unused Reference: 'RFC3719' is defined on line 366, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'RFC5837' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'RFC6232' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'RFC7921' is defined on line 415, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-lsr-dynamic-flooding-04 ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Obsolete normative reference: RFC 5316 (Obsoleted by RFC 9346) Summary: 3 errors (**), 0 flaws (~~), 24 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. Hegde 4 Intended status: Informational Juniper Networks 5 Expires: October 5, 2020 S. Zandi 6 LinkedIn 7 April 3, 2020 9 IS-IS Optimal Distributed Flooding for Dense Topologies 10 draft-white-distoptflood-03 12 Abstract 14 In dense topologies, such as data center fabrics based on the Clos 15 and butterfly fabric topologies, flooding mechanisms designed for 16 sparse topologies, when used in these dense topologies, can 17 "overflood," or carry too many copies of topology and reachability to 18 fabric devices. This results in slower convergence times and higher 19 resource utilization. The modifications to the flooding mechanism in 20 the Intermediate System to Intermediate System (IS-IS) link state 21 protocol described in this document reduce resource utilization to a 22 minimum, while increaseing convergence performance in dense 23 topologies. 25 Note that a Clos fabric is used as the primary example of a desne 26 flooding topology throughout this document. However, the flooding 27 optimizations described in this document apply to any dense topology. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 5, 2020. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.2. Contributors . . . . . . . . . . . . . . . . . . . . . . 3 66 1.3. Experience . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.4. Sample Network . . . . . . . . . . . . . . . . . . . . . 3 68 2. Flooding Modifications . . . . . . . . . . . . . . . . . . . 5 69 2.1. Optimizing Flooding . . . . . . . . . . . . . . . . . . . 5 70 2.2. Flooding Failures . . . . . . . . . . . . . . . . . . . . 6 71 3. Use of Flooding Leaders and Flooding Mechanism Advertisements 6 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 5.2. Informative References . . . . . . . . . . . . . . . . . 8 76 Appendix A. Flooding Optimization Operation . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 1.1. Goals 83 The goal of this draft is to solve one specific set of problems 84 involved in operating a link state protocol in a dense mesh topology. 85 The problem with such topologies is the connectivity density, which 86 causes too much information to be flooded (or too much repeated state 87 to be flooded). Analysis and experiment show, for instance, that in 88 a butterfly fabric of around 2500 intermediate systems, each 89 intermediate system will receive 40+ copies of any changed LSP 90 fragment. This not only wastes bandwidth and processor time, this 91 dramatically slows convergence speed. 93 This document describes a set of modifications to existing IS-IS 94 flooding mechanisms which minimize the number of LSP framgents 95 received by individual intermediate systems, potentially to one copy 96 per intermediate system. The mechanisms described in this document 97 are similar to those implemented in OSPF to support mobile ad-hoc 98 networks, as described in [RFC5449], [RFC5614], and [RFC7182]. These 99 mechanisms have been widely deployed and tested. 101 1.2. Contributors 103 The following people have contributed to this draft: Nikos 104 Triantafillis, Ivan Pepelnjak, Christian Franke, Hannes Gredler, Les 105 Ginsberg, Naiming Shen, Uma Chunduri, Nick Russo, and Rodny Molina. 107 1.3. Experience 109 The modifications described in this draft have been implemented in 110 the FR Routing open source routing stack, and hence are available for 111 testing and modification. The implementation is part of the 112 openfabric daemon, which can be conditionally compiled from isisd. 113 Note openfabricd has further modifications are not described in this 114 document. 116 Lab testing shows these modifications reduce flooding in a large 117 scale emulated butterfly network topology; without these 118 modifications, intermediate systems receive, on average, 40 copies of 119 any changed LSP fragment. With these modifications, intermediate 120 systems recieve, on average, two copies of any changed LSP fragment. 121 In many cases, each intermediate system receives one copy of each 122 changed LSP. In terms of performance, the modifications described 123 here reduce convergence times by around 50%. A network that converges 124 in about 30-40 seconds without these modifications converged in 15-20 125 seconds with these modifications. Processor load times were not 126 checked, as this was an emulated environment. 128 1.4. Sample Network 130 The following spine and leaf fabric will be used to describe these 131 modifications. 133 +----+ +----+ +----+ +----+ +----+ +----+ 134 | 1A | | 1B | | 1C | | 1D | | 1E | | 1F | (T0) 135 +----+ +----+ +----+ +----+ +----+ +----+ 137 +----+ +----+ +----+ +----+ +----+ +----+ 138 | 2A | | 2B | | 2C | | 2D | | 2E | | 2F | (T1) 139 +----+ +----+ +----+ +----+ +----+ +----+ 141 +----+ +----+ +----+ +----+ +----+ +----+ 142 | 3A | | 3B | | 3C | | 3D | | 3E | | 3F | (T2) 143 +----+ +----+ +----+ +----+ +----+ +----+ 145 +----+ +----+ +----+ +----+ +----+ +----+ 146 | 4A | | 4B | | 4C | | 4D | | 4E | | 4F | (T1) 147 +----+ +----+ +----+ +----+ +----+ +----+ 149 +----+ +----+ +----+ +----+ +----+ +----+ 150 | 5A | | 5B | | 5C | | 5D | | 5E | | 5F | (T0) 151 +----+ +----+ +----+ +----+ +----+ +----+ 153 Figure 1 155 To reduce confusion (spine and leaf fabrics are difficult to draw in 156 plain text art), this diagram does not contain the connections 157 between devices. The reader should assume that each device in a 158 given layer is connected to every device in the layer above it. For 159 instance: 161 o 5A is connected to 4A, 4B, 4C, 4D, 4E, and 4F 163 o 5B is connected to 4A, 4B, 4C, 4D, 4E, and 4F 165 o 4A is connected to 3A, 3B, 3C, 3D, 3E, 3F, 5A, 5B, 5C, 5D, 5E, and 166 5F 168 o 4B is connected to 3A, 3B, 3C, 3D, 3E, 3F, 5A, 5B, 5C, 5D, 5E, and 169 5F 171 o etc. 173 The tiers or stages of the fabric are also marked for easier 174 reference. T0 is assumed to be connected to application servers, or 175 rather they are Top of Rack (ToR) intermediate systems. The 176 remaining tiers, T1 and T2, are connected only to the fabric itself. 178 2. Flooding Modifications 180 Flooding is perhaps the most challenging scaling issue for a link 181 state protocol running on a dense, large scale fabric. This section 182 describes modifications to the IS-IS flooding process to reduce 183 flooding load on a dense or mesh topology. 185 2.1. Optimizing Flooding 187 To reduce the flooding of link state information in the form of Link 188 State Protocol Data Units (LSPs), the following tables are required 189 to compute a set of reflooders: 191 o Neighbor List (NL) list: The set of neighbors 193 o Neighbor's Neighbors (NN) list: The set of neighbor's neighbors; 194 this can be calculated by running SPF truncated to two hops 196 o Do Not Reflood (DNR) list: The set of neighbors who should have 197 LSPs (or fragments) who should not reflood LSPs 199 o Reflood (RF) list: The set of neighbors who should flood LSPs (or 200 fragments) to their adjacent neighbors to ensure synchronization 202 NL is set to contain all neighbors, and sorted deterministically (for 203 instance, from the highest IS identifier to the lowest). All 204 intermediate systems within a single fabric SHOULD use the same 205 mechanism for sorting the NL list. NN is set to contain all 206 neighbor's neighbors, or all intermediate systems that are two hops 207 away, as determined by performing a truncated SPF. The DNR and RF 208 tables are initially empty. To begin, the following steps are taken 209 to reduce the size of NN and NL: 211 o Remove all intermediate systems from NL and NN that in the 212 shortest path to the IS that originated the LSP 214 Then, for every IS in NL: 216 o If the current entry in NL is connected to any entries in NN: 218 * Move the IS to RF 220 * Remove the intermediate systems connected to the IS from NN 222 o Else move the IS to DNR 224 The calculation terminates when the NL is empty. 226 When flooding, LSPs transmitted to adjacent neighbors on the RF list 227 will be transmitted normally. Adjacent intermediate systems on this 228 list will reflood received LSPs into the next stage of the topology, 229 ensuring database synchronization. LSPs transmitted to adjacent 230 neighbors on the DNR list, however, MUST be transmitted using a 231 circuit scope PDU as described in [RFC7356]. 233 2.2. Flooding Failures 235 It is possible in some failure modes for flooding to be incomplete 236 because of the flooding optimizations outlined. Specifically, if a 237 reflooder fails, or is somehow disconnected from all the links across 238 which it should be reflooding, it is possible an LSP is only 239 partially flooded through the fabric. To prevent such situations, 240 any IS receiving an LSP transmitted using DNR SHOULD: 242 o Set a short timer; the default should be less than one second 244 o When the timer expires, send a Complete Sequence Number Packet 245 (CSNP) to all neighbors 247 o Process any Partial Sequence Number Packets (PSNPs) as required to 248 resynchronize 250 o If a resynchronization is required, notify the network operator 251 through a network management system 253 3. Use of Flooding Leaders and Flooding Mechanism Advertisements 255 [I-D.ietf-lsr-dynamic-flooding], section 5.1.1, describes the 256 election of a flooding domain leader, which can advertise the kind of 257 flooding reduction mechanism used in the flooding domain. 258 Implementations of this draft MAY implement the election and 259 advertisement of a flooding domain leader as described in section 260 5.1.1 of [I-D.ietf-lsr-dynamic-flooding]. If the election of a 261 flooding domain leader is implemented, implementations SHOULD also 262 advertise the flooding mechanism using the IS-IS Dynamic Flooding 263 Sub-TLV described in section 5.1.2 of 264 [I-D.ietf-lsr-dynamic-flooding], using Algorithm number (TBD). 266 4. Security Considerations 268 This document outlines modifications to the IS-IS protocol for 269 operation on high density network topologies. Implementations SHOULD 270 implement IS-IS cryptographic authentication, as described in 271 [RFC5304], and should enable other security measures in accordance 272 with best common practices for the IS-IS protocol. 274 5. References 276 5.1. Normative References 278 [I-D.ietf-lsr-dynamic-flooding] 279 Li, T., Psenak, P., Ginsberg, L., Chen, H., Przygienda, 280 T., Cooper, D., Jalil, L., and S. Dontula, "Dynamic 281 Flooding on Dense Graphs", draft-ietf-lsr-dynamic- 282 flooding-04 (work in progress), November 2019. 284 [ISO10589] 285 International Organization for Standardization, 286 "Intermediate system to Intermediate system intra-domain 287 routeing information exchange protocol for use in 288 conjunction with the protocol for providing the 289 connectionless-mode Network Service (ISO 8473)", ISO/ 290 IEC 10589:2002, Second Edition, Nov 2002. 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, 294 DOI 10.17487/RFC2119, March 1997, 295 . 297 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 298 DOI 10.17487/RFC2629, June 1999, 299 . 301 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 302 Topology (MT) Routing in Intermediate System to 303 Intermediate Systems (IS-ISs)", RFC 5120, 304 DOI 10.17487/RFC5120, February 2008, 305 . 307 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 308 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 309 October 2008, . 311 [RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way 312 Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, 313 DOI 10.17487/RFC5303, October 2008, 314 . 316 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 317 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 318 2008, . 320 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 321 DOI 10.17487/RFC5308, October 2008, 322 . 324 [RFC5309] Shen, N., Ed. and A. Zinin, Ed., "Point-to-Point Operation 325 over LAN in Link State Routing Protocols", RFC 5309, 326 DOI 10.17487/RFC5309, October 2008, 327 . 329 [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. 330 Shand, "Simplified Extension of Link State PDU (LSP) Space 331 for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, 332 . 334 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 335 Support of Inter-Autonomous System (AS) MPLS and GMPLS 336 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 337 December 2008, . 339 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 340 Scope Link State PDUs (LSPs)", RFC 7356, 341 DOI 10.17487/RFC7356, September 2014, 342 . 344 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 345 for Advertising Router Information", RFC 7981, 346 DOI 10.17487/RFC7981, October 2016, 347 . 349 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 350 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 351 May 2017, . 353 5.2. Informative References 355 [I-D.ietf-isis-segment-routing-extensions] 356 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 357 Gredler, H., and B. Decraene, "IS-IS Extensions for 358 Segment Routing", draft-ietf-isis-segment-routing- 359 extensions-25 (work in progress), May 2019. 361 [RFC3277] McPherson, D., "Intermediate System to Intermediate System 362 (IS-IS) Transient Blackhole Avoidance", RFC 3277, 363 DOI 10.17487/RFC3277, April 2002, 364 . 366 [RFC3719] Parker, J., Ed., "Recommendations for Interoperable 367 Networks using Intermediate System to Intermediate System 368 (IS-IS)", RFC 3719, DOI 10.17487/RFC3719, February 2004, 369 . 371 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 372 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 373 DOI 10.17487/RFC4271, January 2006, 374 . 376 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 377 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 378 2008, . 380 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 381 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 382 DOI 10.17487/RFC5440, March 2009, 383 . 385 [RFC5449] Baccelli, E., Jacquet, P., Nguyen, D., and T. Clausen, 386 "OSPF Multipoint Relay (MPR) Extension for Ad Hoc 387 Networks", RFC 5449, DOI 10.17487/RFC5449, February 2009, 388 . 390 [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) 391 Extension of OSPF Using Connected Dominating Set (CDS) 392 Flooding", RFC 5614, DOI 10.17487/RFC5614, August 2009, 393 . 395 [RFC5820] Roy, A., Ed. and M. Chandra, Ed., "Extensions to OSPF to 396 Support Mobile Ad Hoc Networking", RFC 5820, 397 DOI 10.17487/RFC5820, March 2010, 398 . 400 [RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, 401 N., and JR. Rivers, "Extending ICMP for Interface and 402 Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, 403 April 2010, . 405 [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 406 Originator Identification TLV for IS-IS", RFC 6232, 407 DOI 10.17487/RFC6232, May 2011, 408 . 410 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 411 Check Value and Timestamp TLV Definitions for Mobile Ad 412 Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182, 413 April 2014, . 415 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 416 Nadeau, "An Architecture for the Interface to the Routing 417 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 418 . 420 Appendix A. Flooding Optimization Operation 422 Recent testing has shown that flooding is largely a "non-issue" in 423 terms of scaling when using high speed links connecting intermediate 424 systems with reasonable processing power and memory. However, 425 testing has also shown that flooding will impact convergence speed 426 even in such environments, and flooding optimization has a major 427 impact on the performance of a link state protocol in resource 428 constrained environments. Some thoughts on flooding optimization in 429 general, and the flooding optimization contained in this document, 430 follow. 432 There are two general classes of flooding optimization available for 433 link state protocols. The first class of optimization relies on a 434 centralized service or server to gather the link state information 435 and redistribute it back into the intermediate systems making up the 436 fabric. Such solutions are attractive in many, but not all, 437 environments; hence these systems compliment, rather than compete 438 with, the system described here. Systems relying on a service or 439 server necessarily also rely on connectivity to that service or 440 server, either through an out-of-band network or connectivity through 441 the fabric itself. Because of this, these mechanisms do not apply to 442 all deployments; some deployments require underlying reachability 443 regardless of connectivity to an outside service or server. 445 The second possibility is to create a fully distributed system that 446 floods the minimal amount of information possible to every 447 intermediate system. The system described in this draft is an 448 example of such a system. Again, there are many ways to accomplish 449 this goal, but simplicity is a primary goal of the system described 450 in this draft. 452 The system described here divides the work into two different parts; 453 forward and reverse optimization. The forward optimization begins by 454 finding the set of intermediate systems two hops away from the 455 flooding device, and choosing a subset of connected neighbors that 456 will successfully reach this entire set of intermediate systems, as 457 shown in the diagram below. 459 G 460 | 461 A B C--+ 462 | | | | 463 +--D--+ E H 464 | | | 465 +----F--+--+ 467 Figure 2 469 If F is flooding some piece of information, then it will find the 470 entire set of intermediate systems within two hops by discovering its 471 neighbors and their neighbors from the local LSDB. This will include 472 A, B, C, D, and E--but not G. From this set, F can determine that D 473 can reach A and B, while a single flood to either E or H will reach 474 C. Hence F can flood to D and either E or H to reach C. F can 475 choose to flood to D and E normally. Because H still needs to 476 receive this new LSP (or fragment!), but does not need to reflood to 477 C, F can send the LSP using link local signaling. In this case, H 478 will receive and process the new LSP, but not reflood it. 480 Rather than carrying the information necessary through hello 481 extensions, as is done in [RFC5820], the neighbors are allowed to 482 complete initial synchronization, and then a truncated shortest path 483 tree is built to determine the "two hop neighborhood." This has the 484 advantage of using mechanisms already used in IS-IS, rather than 485 adding new processes. The risk with this process is any LSPs flooded 486 through the network before this initial calculation takes place will 487 be suboptimal. This "two hop neighborhood" process has been used in 488 OSPF deployments for a number of years, and has proven stable in 489 practice. 491 Rather than setting a timer for reflooding, the implementation 492 described here uses IS-IS' ability to describe the entire database 493 using a CSNP to ensure flooding is successful. This adds some small 494 amount of overhead, so there is some balance between optimal flooding 495 and ensuring flooding is complete. 497 The reverse optimization is simpler. It relies on the observation 498 that any intermediate system between the local IS and the origin of 499 the LSP, other than in the case of floods removing an LSP from the 500 shared LSDB, should have already received a copy of the LSP. For 501 instance, if F originates an LSP in the figure above, and E refloods 502 the LSP to C, C does not need to reflood back to F if F is on its 503 shortest path tree towards F. It is obvious this is not a "perfect" 504 optimization. A perfect optimization would block flooding back along 505 a directed acyclic graph towards the originator. Using the SPT, 506 however, is a quick way to reduce flooding without performing more 507 calculations. 509 The combination of these two optimizations have been seen, in 510 testing, to reduce the number of copies any IS receives from the tens 511 to precisely one. 513 Authors' Addresses 515 Russ White 516 Juniper Networks 518 Email: russ@riw.us 520 Shraddha Hegde 521 Juniper Networks 523 Email: shraddha@juniper.net 525 Shawn Zandi 526 LinkedIn 528 Email: szandi@linkedin.com