idnits 2.17.1 draft-ietf-lsr-dynamic-flooding-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 : ---------------------------------------------------------------------------- ** There are 28 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 'MUST not' in this paragraph: So long as the Flooding Request TLV is being received flooding MUST not be disabled for any of the Circuit Types or Flooding Scopes present in the Flooding Request TLV even if the connection between the neighbors is removed from the flooding topology. Flooding for such Circuit Types or Flooding Scopes MUST continue on the link and be considered as temporarily enabled. == 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 'MUST not' in this paragraph: So long as the FR-bit is being received in the OSPF LLS Extended Options and Flags TLV for an area, flooding MUST not be disabled in such area even if the connection between the neighbors is removed from the flooding topology. Flooding for such area MUST continue on the link and be considered as temporarily enabled. -- The document date (February 25, 2019) is 1884 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) == Unused Reference: 'RFC5613' is defined on line 1583, but no explicit reference was found in the text == Unused Reference: 'RFC7120' is defined on line 1588, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Li, Ed. 3 Internet-Draft Arista Networks 4 Intended status: Standards Track P. Psenak, Ed. 5 Expires: August 29, 2019 L. Ginsberg 6 Cisco Systems, Inc. 7 T. Przygienda 8 Juniper Networks, Inc. 9 D. Cooper 10 CenturyLink 11 L. Jalil 12 Verizon 13 S. Dontula 14 ATT 15 February 25, 2019 17 Dynamic Flooding on Dense Graphs 18 draft-ietf-lsr-dynamic-flooding-00 20 Abstract 22 Routing with link state protocols in dense network topologies can 23 result in sub-optimal convergence times due to the overhead 24 associated with flooding. This can be addressed by decreasing the 25 flooding topology so that it is less dense. 27 This document discusses the problem in some depth and an 28 architectural solution. Specific protocol changes for IS-IS, OSPFv2, 29 and OSPFv3 are described in this document. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 29, 2019. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 67 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Solution Requirements . . . . . . . . . . . . . . . . . . . . 5 69 4. Dynamic Flooding . . . . . . . . . . . . . . . . . . . . . . 5 70 4.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 7 71 4.2. Leader election . . . . . . . . . . . . . . . . . . . . . 7 72 4.3. Computing the Flooding Topology . . . . . . . . . . . . . 8 73 4.4. Topologies on Complete Bipartite Graphs . . . . . . . . . 9 74 4.4.1. A Minimal Flooding Topology . . . . . . . . . . . . . 9 75 4.4.2. Xia Topologies . . . . . . . . . . . . . . . . . . . 9 76 4.4.3. Optimization . . . . . . . . . . . . . . . . . . . . 10 77 4.5. Encoding the Flooding Topology . . . . . . . . . . . . . 11 78 5. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 11 79 5.1. IS-IS TLVs . . . . . . . . . . . . . . . . . . . . . . . 11 80 5.1.1. IS-IS Area Leader Sub-TLV . . . . . . . . . . . . . . 11 81 5.1.2. IS-IS Dynamic Flooding Sub-TLV . . . . . . . . . . . 12 82 5.1.3. IS-IS Area System IDs TLV . . . . . . . . . . . . . . 13 83 5.1.4. IS-IS Flooding Path TLV . . . . . . . . . . . . . . . 14 84 5.1.5. IS-IS Flooding Request TLV . . . . . . . . . . . . . 15 85 5.2. OSPF LSAs and TLVs . . . . . . . . . . . . . . . . . . . 16 86 5.2.1. OSPF Area Leader Sub-TLV . . . . . . . . . . . . . . 17 87 5.2.2. OSPF Dynamic Flooding Sub-TLV . . . . . . . . . . . . 17 88 5.2.3. OSPFv2 Dynamic Flooding Opaque LSA . . . . . . . . . 18 89 5.2.4. OSPFv3 Dynamic Flooding LSA . . . . . . . . . . . . . 19 90 5.2.5. OSPF Area Router IDs TLV . . . . . . . . . . . . . . 20 91 5.2.6. OSPF Flooding Path TLV . . . . . . . . . . . . . . . 21 92 5.2.7. OSPF Flooding Request Bit . . . . . . . . . . . . . . 22 93 6. Behavioral Specification . . . . . . . . . . . . . . . . . . 23 94 6.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 23 95 6.2. Flooding Topology . . . . . . . . . . . . . . . . . . . . 23 96 6.3. Leader Election . . . . . . . . . . . . . . . . . . . . . 24 97 6.4. Area Leader Responsibilities . . . . . . . . . . . . . . 24 98 6.5. Distributed Flooding Topology Calculation . . . . . . . . 24 99 6.6. Flooding Behavior . . . . . . . . . . . . . . . . . . . . 25 100 6.7. Treatment of Topology Events . . . . . . . . . . . . . . 25 101 6.7.1. Temporary Addition of Link to Flooding Topology . . . 26 102 6.7.2. Local Link Addition . . . . . . . . . . . . . . . . . 26 103 6.7.3. Node Addition . . . . . . . . . . . . . . . . . . . . 27 104 6.7.4. Failures of Link Not on Flooding Topology . . . . . . 27 105 6.7.5. Failures of Link On the Flooding Topology . . . . . . 28 106 6.7.6. Node Deletion . . . . . . . . . . . . . . . . . . . . 28 107 6.7.7. Local Link Addition to the Flooding Topology . . . . 28 108 6.7.8. Local Link Deletion from the Flooding Topology . . . 29 109 6.7.9. Treatment of Disconnected Adjacent Nodes . . . . . . 29 110 6.7.10. Failure of the Area Leader . . . . . . . . . . . . . 29 111 6.7.11. Recovery from Multiple Failures . . . . . . . . . . . 30 112 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 113 7.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 30 114 7.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 31 115 7.2.1. OSPF Dynamic Flooding LSA TLVs Registry . . . . . . . 32 116 7.3. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 117 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 118 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 119 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 120 10.1. Normative References . . . . . . . . . . . . . . . . . . 34 121 10.2. Informative References . . . . . . . . . . . . . . . . . 35 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 124 1. Introduction 126 In recent years, there has been increased focus on how to address the 127 dynamic routing of networks that have a bipartite (a.k.a. spine-leaf 128 or leaf-spine), Clos [Clos], or Fat Tree [Leiserson] topology. 129 Conventional Interior Gateway Protocols (IGPs, i.e., IS-IS 130 [ISO10589], OSPFv2 [RFC2328], and OSPFv3 [RFC5340]) under-perform, 131 redundantly flooding information throughout the dense topology, 132 leading to overloaded control plane inputs and thereby creating 133 operational issues. For practical considerations, network architects 134 have resorted to applying unconventional techniques to address the 135 problem, e.g., applying BGP in the data center [RFC7938]. However it 136 is very clear that using an Exterior Gateway Protocol as an IGP is 137 sub-optimal, if only due to the configuration overhead. 139 The primary issue that is demonstrated when conventional mechanisms 140 are applied is the poor reaction of the network to topology changes. 141 Normal link state routing protocols rely on a flooding algorithm for 142 state distribution within an area. In a dense topology, this 143 flooding algorithm is highly redundant, resulting in unnecessary 144 overhead. Each node in the topology receives each link state update 145 multiple times. Ultimately, all of the redundant copies will be 146 discarded, but only after they have reached the control plane and 147 been processed. This creates issues because significant link state 148 database updates can become queued behind many redundant copies of 149 another update. This delays convergence as the link state database 150 does not stabilize promptly. 152 In a real world implementation, the packet queues leading to the 153 control plane are necessarily of finite size, so if the flooding rate 154 exceeds the update processing rate for long enough, the control plane 155 will be obligated to drop incoming updates. If these lost updates 156 are of significance, this will further delay stabilization of the 157 link state database and the convergence of the network. 159 This is not a new problem. Historically, when routing protocols have 160 been deployed in networks where the underlying topology is a complete 161 graph, there have been similar issues. This was more common when the 162 underlying link layer fabric presented the network layer with a full 163 mesh of virtual connections. This was addressed by reducing the 164 flooding topology through IS-IS Mesh Groups [RFC2973], but this 165 approach requires careful configuration of the flooding topology. 167 Thus, the root problem is not limited to massively scalable data 168 centers. It exists with any dense topology at scale. 170 This problem is not entirely surprising. Link state routing 171 protocols were conceived when links were very expensive and 172 topologies were sparse. The fact that those same designs are sub- 173 optimal in a dense topology should not come as a huge surprise. The 174 fundamental premise that was addressed by the original designs was an 175 environment of extreme cost and scarcity. Technology has progressed 176 to the point where links are cheap and common. This represents a 177 complete reversal in the economic fundamentals of network 178 engineering. The original designs are to be commended for continuing 179 to provide correct operation to this point, and optimizations for 180 operation in today's environment are to be expected. 182 1.1. Requirements Language 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in RFC 2119 [RFC2119]. 188 2. Problem Statement 190 In a dense topology, the flooding algorithm that is the heart of 191 conventional link state routing protocols causes a great deal of 192 redundant messaging. This is exacerbated by scale. While the 193 protocol can survive this combination, the redundant messaging is 194 unnecessary overhead and delays convergence. Thus, the problem is to 195 provide routing in dense, scalable topologies with rapid convergence. 197 3. Solution Requirements 199 A solution to this problem must then meet the following requirements: 201 Requirement 1 Provide a dynamic routing solution. Reachability 202 must be restored after any topology change. 204 Requirement 2 Provide a significant improvement in convergence. 206 Requirement 3 The solution should address a variety of dense 207 topologies. Just addressing a complete bipartite topology such 208 as K5,8 is insufficient. Multi-stage Clos topologies must also 209 be addressed, as well as topologies that are slight variants. 210 Addressing complete graphs is a good demonstration of generality. 212 Requirement 4 There must be no single point of failure. The loss 213 of any link or node should not unduly hinder convergence. 215 Requirement 5 Dense topologies are subgraphs of much larger 216 topologies. Operational efficiency requires that the dense 217 subgraph not operate in a radically different manner than the 218 remainder of the topology. While some operational differences 219 are permissible, they should be minimized. Changes to nodes 220 outside of the dense subgraph are not acceptable. These 221 situations occur when massively scaled data centers are part of 222 an overall larger wide-area network. Having a second protocol 223 operating just on this subgraph would add much more complexity at 224 the edge of the subgraph where the two protocols would have to 225 inter-operate. 227 4. Dynamic Flooding 229 We have observed that the combination of the dense topology and 230 flooding on the physical topology in a scalable network is sub- 231 optimal. However, if we decouple the flooding topology from the 232 physical topology and only flood on a greatly reduced portion of that 233 topology, we can have efficient flooding and retain all of the 234 resilience of existing protocols. A node that supports flooding on 235 the decoupled flooding topology is said to support dynamic flooding. 237 In this idea, the flooding topology is computed within an IGP area 238 with the dense topology either centrally on an elected node, termed 239 the Area Leader, or in a distributed manner on all nodes that are 240 supporting Dynamic Flooding. If the flooding topology is computed 241 centrally, it is encoded into and distributed as part of the normal 242 link state database. We call this the centralized mode of operation. 243 If the flooding topology is computed in a distributed fashion, we 244 call this the distributed mode of operation. Nodes within such an 245 IGP area would only flood on the flooding topology. On links outside 246 of the normal flooding topology, normal database synchronization 247 mechanisms (i.e., OSPF database exchange, IS-IS CSNPs) would apply, 248 but flooding may not. Details are described in Section 6. New link 249 state information that arrives from outside of the flooding topology 250 suggests that the sender has a different or no flooding topology 251 information and that the link state update should be flooded on the 252 flooding topology as well. 254 The flooding topology covers the full set of nodes within the area, 255 but excludes some of the links that standard flooding would employ. 257 Since the flooding topology is computed prior to topology changes, it 258 does not factor into the convergence time and can be done when the 259 topology is stable. The speed of the computation and its 260 distribution, in the case of a centralized mode, is not a significant 261 issue. 263 If a node does not have any flooding topology information when it 264 receives new link state information, it should flood according to 265 standard flooding rules. This situation will occur when the dense 266 topology is first established, but is unlikely to recur. 268 When centralized mode is used and if, during a transient, there are 269 multiple flooding topologies being advertised, then nodes should 270 flood link state updates on all of the flooding topologies. Each 271 node should locally evaluate the election of the Area Leader for the 272 IGP area and first flood on its flooding topology. The rationale 273 behind this is straightforward: if there is a transient and there has 274 been a recent change in Area Leader, then propagating topology 275 information promptly along the most likely flooding topology should 276 be the priority. 278 During transients, it is possible that loops will form in the 279 flooding topology. This is not problematic, as the legacy flooding 280 rules would cause duplicate updates to be ignored. Similarly, during 281 transients, it is possible that the flooding topology may become 282 disconnected. Section 6.7.11 discusses how such conditions are 283 handled. 285 4.1. Applicability 287 In a complete graph, this approach is appealing because it 288 drastically decreases the flooding topology without the manual 289 configuration of mesh groups. By controlling the diameter of the 290 flooding topology, as well as the maximum degree node in the flooding 291 topology, convergence time goals can be met and the stability of the 292 control plane can be assured. 294 Similarly, in a massively scaled data center, where there are many 295 opportunities for redundant flooding, this mechanism ensures that 296 flooding is redundant, with each leaf and spine well connected, while 297 ensuring that no update need make too many hops and that no node 298 shares an undue portion of the flooding effort. 300 In a network where only a portion of the nodes support Dynamic 301 Flooding, the remaining nodes will continue to perform standard 302 flooding. This is not an issue for correctness, as no node can 303 become isolated. 305 Flooding that is initiated by nodes that support Dynamic Flooding 306 will remain within the flooding topology until it reaches a legacy 307 node, which will resume legacy flooding. Standard flooding will be 308 bounded by nodes supporting Dynamic Flooding, which can help limit 309 the propagation of unnecessary flooding. Whether or not the network 310 can remain stable in this condition is unknown and may be very 311 dependent on the number and location of the nodes that support 312 Dynamic Flooding. 314 During incremental deployment of dynamic flooding an area will 315 consist of one or more sets of connected nodes that support dynamic 316 flooding and one or more sets of connected nodes that do not, i.e., 317 nodes that support standard flooding. The flooding topology is the 318 union of these sets of nodes. Each set of nodes that does not 319 support dynamic flooding needs to be part of the flooding topology 320 and such a set of nodes may provide connectivity between two or more 321 sets of nodes that support dynamic flooding. 323 4.2. Leader election 325 A single node within the dense topology is elected as an Area Leader. 327 A generalization of the mechanisms used in existing Designated Router 328 (OSPF) or Designated Intermediate-System (IS-IS) elections suffices. 329 The elected node is known as the Area Leader. 331 In the case of centralized mode, the Area Leader is responsible for 332 computing and distributing the flooding topology. When a new Area 333 Leader is elected and has distributed new flooding topology 334 information, then any prior Area Leaders should withdraw any of their 335 flooding topology information from their link state database entries. 337 In the case of distributed mode, the distributed algorithm advertised 338 by the Area Leader MUST be used by all nodes that participate in 339 Dynamic Flooding. 341 Not every node needs to be a candidate to be Area Leader within an 342 area, as a single candidate is sufficient for correct operation. For 343 redundancy, however, it is strongly RECOMMENDED that there be 344 multiple candidates. 346 4.3. Computing the Flooding Topology 348 There is a great deal of flexibility in how the flooding topology may 349 be computed. For resilience, it needs to at least contain a cycle of 350 all nodes in the dense subgraph. However, additional links could be 351 added to decrease the convergence time. The trade-off between the 352 density of the flooding topology and the convergence time is a matter 353 for further study. The exact algorithm for computing the flooding 354 topology in the case of the centralized computation need not be 355 standardized, as it is not an interoperability issue. Only the 356 encoding of the result needs to be documented. In the case of 357 distributed mode, all nodes in the IGP area need to use the same 358 algorithm to compute the flooding topology. It is possible to use 359 private algorithms to compute flooding topology, so long as all nodes 360 in the IGP area use the same algorithm. 362 While the flooding topology should be a covering cycle, it need not 363 be a Hamiltonian cycle where each node appears only once. In fact, 364 in many relevant topologies this will not be possible e.g., K5,8. 365 This is fortunate, as computing a Hamiltonian cycle is known to be 366 NP-complete. 368 A simple algorithm to compute the topology for a complete bipartite 369 graph is to simply select unvisited nodes on each side of the graph 370 until both sides are completely visited. If the number of nodes on 371 each side of the graph are unequal, then revisiting nodes on the less 372 populated side of the graph will be inevitable. This algorithm can 373 run in O(N) time, so is quite efficient. 375 While a simple cycle is adequate for correctness and resiliency, it 376 may not be optimal for convergence. At scale, a cycle may have a 377 diameter that is half the number of nodes in the graph. This could 378 cause an undue delay in link state update propagation. Therefore it 379 may be useful to have a bound on the diameter of the flooding 380 topology. Introducing more links into the flooding topology would 381 reduce the diameter, but at the trade-off of possibly adding 382 redundant messaging. The optimal trade-off between convergence time 383 and graph diameter is for further study. 385 Similarly, if additional redundancy is added to the flooding 386 topology, specific nodes in that topology may end up with a very high 387 degree. This could result in overloading the control plane of those 388 nodes, resulting in poor convergence. Thus, it may be optimal to 389 have an upper bound on the degree of nodes in the flooding topology. 390 Again, the optimal trade-off between graph diameter, node degree, and 391 convergence time, and topology computation time is for further study. 393 If the leader chooses to include a multi-node broadcast LAN segment 394 as part of the flooding topology, all of the connectivity to that LAN 395 segment should be included as well. Once updates are flooded onto 396 the LAN, they will be received by every attached node. 398 4.4. Topologies on Complete Bipartite Graphs 400 Complete bipartite graph topologies have become popular for data 401 center applications and are commonly called leaf-spine or spine-leaf 402 topologies. In this section, we discuss some flooding topologies 403 that are of particular interest in these networks. 405 4.4.1. A Minimal Flooding Topology 407 We define a Minimal Flooding Topology on a complete bipartite graph 408 as one in which the topology is connected and each node has at least 409 degree two. This is of interest because it guarantees that the 410 flooding topology has no single points of failure. 412 In practice, this implies that every leaf node in the flooding 413 topology will have a degree of two. As there are usually more leaves 414 than spines, the degree of the spines will be higher, but the load on 415 the individual spines can be evenly distributed. 417 This type of flooding topology is also of interest because it scales 418 well. As the number of leaves increases, we can construct flooding 419 topologies that perform well. Specifically, for n spines and m 420 leaves, if m >= n(n/2-1), then there is a flooding topology that has 421 a diameter of four. 423 4.4.2. Xia Topologies 425 We define a Xia Topology on a complete bipartite graph as one in 426 which all spine nodes are bi-connected through leaves with degree 427 two, but the remaining leaves all have degree one and are evenly 428 distributed across the spines. 430 Constructively, we can create a Xia topology by iterating through the 431 spines. Each spine can be connected to the next spine by selecting 432 any unused leaf. Since leaves are connected to all spines, all 433 leaves will have a connection to both the first and second spine and 434 we can therefore choose any leaf without loss of generality. 435 Continuing this iteration across all of the spines, selecting a new 436 leaf at each iteration, will result in a path that connects all 437 spines. Adding one more leaf between the last and first spine will 438 produce a cycle of n spines and n leaves. 440 At this point, m-n leaves remain unconnected. These can be 441 distributed evenly across the remaining spines, connected by a single 442 link. 444 Xia topologies represent a compromise that trades off increased risk 445 and decreased performance for lower flooding amplification. Xia 446 topologies will have a larger diameter. For m spines, the diameter 447 will be m + 2. 449 In a Xia topology, some leaves are singly connected. This represents 450 a risk in that in some failures, convergence may be delayed. 451 However, there may be some alternate behaviors that can be employed 452 to mitigate these risks. If a leaf node sees that its single link on 453 the flooding topology has failed, it can compensate by performing a 454 database synchronization check with a different spine. Similarly, if 455 a leaf determines that its connected spine on the flooding topology 456 has failed, it can compensate by performing a database 457 synchronization check with a different spine. In both of these 458 cases, the synchronization check is intended to ameliorate any delays 459 in link state propagation due to the fragmentation of the flooding 460 topology. 462 The benefit of this topology is that flooding load is easily 463 understood. Each node in the spine cycle will never receive an 464 update more than twice. For m leaves and n spines, a spine never 465 transmits more than (m/n +1) updates. 467 4.4.3. Optimization 469 If two nodes are adjacent on the flooding topology and there are a 470 set of parallel links between them, then any given update MUST be 471 flooded over a single one of those links. Selection of the specific 472 link is implementation specific. 474 4.5. Encoding the Flooding Topology 476 There are a variety of ways that the flooding topology could be 477 encoded efficiently. If the topology was only a cycle, a simple list 478 of the nodes in the topology would suffice. However, this is 479 insufficiently flexible as it would require a slightly different 480 encoding scheme as soon as a single additional link is added. 481 Instead, we choose to encode the flooding topology as a set of 482 intersecting paths, where each path is a set of connected edges. 484 Other encodings are certainly possible. We have attempted to make a 485 useful trade off between simplicity, generality, and space. 487 5. Protocol Elements 489 5.1. IS-IS TLVs 491 The following TLVs/sub-TLVs are added to IS-IS: 493 1. A sub-TLV that an IS may inject into its LSP to indicate its 494 preference for becoming Area Leader. 496 2. A sub-TLV that an IS may inject into its LSP to indicate that it 497 supports Dynamic Flooding and the algorithms that it supports for 498 distributed mode, if any. 500 3. A TLV to carry the list of system IDs that compromise the 501 flooding topology for the area. 503 4. A TLV to carry a path which is part of the flooding topology 505 5. A TLV that requests flooding from the adjacent node 507 5.1.1. IS-IS Area Leader Sub-TLV 509 The Area Leader Sub-TLV allows a system to: 511 1. Indicate its eligibility and priority for becoming Area Leader. 513 2. Indicate whether centralized or distributed mode is to be used to 514 compute the flooding topology in the area. 516 3. Indicate the algorithm identifier for the algorithm that is used 517 to compute the flooding topology in distributed mode. 519 Intermediate Systems (nodes) that are not advertising this Sub-TLV 520 are not eligible to become Area Leader. 522 The Area Leader is the node with the numerically highest Area Leader 523 priority in the area. In the event of ties, the node with the 524 numerically highest system ID is the Area Leader. Due to transients 525 during database flooding, different nodes may not agree on the Area 526 Leader. 528 The Area Leader Sub-TLV is advertised as a Sub-TLV of the IS-IS 529 Router Capability TLV-242 that is defined in [RFC7981] and has the 530 following format: 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Type | Length | Priority | Algorithm | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 Type: TBD1 540 Length: 2 542 Priority: 0-255, unsigned integer 544 Algorithm: a numeric identifier in the range 0-255 that identifies 545 the algorithm used to calculate the flooding topology. The 546 following values are defined: 548 0: Centralized computation by the Area Leader. 550 1-127: Standardized distributed algorithms. Individual values 551 are are to be assigned according to the "Specification 552 Required" policy defined in [RFC8126] (see Section 7.3). 554 128-254: Private distributed algorithms. Individual values are 555 are to be assigned according to the "Private Use" policy 556 defined in [RFC8126] (see Section 7.3). 558 255: Reserved 560 5.1.2. IS-IS Dynamic Flooding Sub-TLV 562 The Dynamic Flooding Sub-TLV allows a system to: 564 1. Indicate that it supports Dynamic Flooding. This is indicated by 565 the advertisement of this Sub-TLV. 567 2. Indicate the set of algorithms that it supports for distributed 568 mode, if any. 570 In incremental deployments, understanding which nodes support Dynamic 571 Flooding can be used to optimize the flooding topology. In 572 distributed mode, knowing the capabilities of the nodes can allow the 573 Area Leader to select the optimal algorithm. 575 The Dynamic Flooding Sub-TLV is advertised as a Sub-TLV of the IS-IS 576 Router Capability TLV (242) [RFC7981] and has the following format: 578 0 1 2 3 579 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 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Type | Length | Algorithm... | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 Type: TBD7 586 Length: 0-255; number of Algorithms 588 Algorithm: zero or more numeric identifiers in the range 0-255 589 that identifies the algorithm used to calculate the flooding 590 topology, as described in Section 5.1.1. 592 5.1.3. IS-IS Area System IDs TLV 594 IS-IS Area System IDs TLV is only used in centralized mode. 596 The Area System IDs TLV is used by the Area Leader to enumerate the 597 system IDs that it has used in computing the flooding topology. 598 Conceptually, the Area Leader creates a list of system IDs for all 599 nodes in the area, assigning indices to each system, starting with 600 index 0. 602 Because the space in a single TLV is small, more than one TLV may be 603 required to encode all of the system IDs in the area. This TLV may 604 be present in multiple LSPs. 606 The format of the Area System IDs TLV is: 608 0 1 2 3 609 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 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Type | Length | Starting Index | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 |L| Reserved | System IDs ... 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 System IDs continued .... 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 Type: TBD2 620 Length: 3 + (System ID length * (number of System IDs)) 622 Starting index: The index of the first system ID that appears in 623 this TLV. 625 L (Last): This bit is set if the index of the last system ID that 626 appears in this TLV is equal to the last index in the full list of 627 system IDs for the area. 629 System IDs: A concatenated list of system IDs for the area. 631 If there are multiple IS-IS Area System IDs TLVs with the L bit set 632 advertised by the same node, the TLV which specifies the smaller 633 maximum index is used and the other TLV(s) with L bit set are 634 ignored. TLVs which specify system IDs with indices greater than 635 that specified by the TLV with the L bit set are also ignored. 637 5.1.4. IS-IS Flooding Path TLV 639 IS-IS Flooding Path TLV is only used in centralized mode. 641 The Flooding Path TLV is used to denote a path in the flooding 642 topology. The goal is an efficient encoding of the links of the 643 topology. A single link is a simple case of a path that only covers 644 two nodes. A connected path may be described as a sequence of 645 indices: (I1, I2, I3, ...), denoting a link from the system with 646 index 1 to the system with index 2, a link from the system with index 647 2 to the system with index 3, and so on. 649 If a path exceeds the size that can be stored in a single TLV, then 650 the path may be distributed across multiple TLVs by the replication 651 of a single system index. 653 Complex topologies that are not a single path can be described using 654 multiple TLVs. 656 The Flooding Path TLV contains a list of system indices relative to 657 the systems advertised through the Area System IDs TLV. At least 2 658 indices must be included in the TLV. Due to the length restriction 659 of TLVs, this TLV can contain at most 126 system indices. 661 The Flooding Path TLV has the format: 663 0 1 2 3 664 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 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Type | Length | Starting Index | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | Index 2 | Additional indices ... 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 Type: TBD3 673 Length: 2 * (number of indices in the path) 675 Starting index: The index of the first system in the path. 677 Index 2: The index of the next system in the path. 679 Additional indices (optional): A sequence of additional indices to 680 systems along the path. 682 5.1.5. IS-IS Flooding Request TLV 684 The Flooding Request TLV allows a system to request an adjacent node 685 to enable flooding towards it on a specific link in the case where 686 the connection to adjacent node is not part of the existing flooding 687 topology. 689 Nodes that support Dynamic Flooding MAY include the Flooding Request 690 TLV in its IIH PDUs. 692 The Flooding Request TLV has the format: 694 0 1 2 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Type | Length | Circuit Type |R| Scope | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 |R| ... | 700 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 Type: TBD9 704 Length: 1 + number of advertised Flooding Scopes 706 Circuit Type - circuit type as specified in IS-IS [ISO10589] 708 R bit: MUST be 0 and is ignored on receipt. 710 Scope: Flooding Scope for which the flooding is requested as 711 defined by LSP Flooding Scope Identifier Registry defined by 712 [RFC7356]. Inclusion of flooding scopes is optional and is only 713 necessary if [RFC7356] is supported. 715 Circuit Flooding Scope MUST NOT be sent in the Flooding Request TLV 716 and MUST be ignore if received. 718 If flooding was disabled on the received link due to Dynamic 719 Flooding, then flooding MUST be temporarily enabled over the link for 720 the specified Circuit Type(s) and Flooding Scope(s) received in the 721 in the Flooding Request TLV. Flooding MUST be enabled until the 722 Circuit Type or Flooding Scope is no longer advertised in the 723 Flooding Request TLV or the TLV no longer appears in IIH PDUs 724 received on the link. 726 When the flooding is temporarily enabled on the link for any Circuit 727 Type or Flooding Scope due to received Flooding Request TLV, the 728 receiver MUST perform standard database synchronization for the 729 corresponding Circuit Type(s) and Flooding Scope(s) on the link. In 730 the case of IS-IS, this results in setting SRM bit for all related 731 LSPs on the link and sending CSNPs. 733 So long as the Flooding Request TLV is being received flooding MUST 734 not be disabled for any of the Circuit Types or Flooding Scopes 735 present in the Flooding Request TLV even if the connection between 736 the neighbors is removed from the flooding topology. Flooding for 737 such Circuit Types or Flooding Scopes MUST continue on the link and 738 be considered as temporarily enabled. 740 5.2. OSPF LSAs and TLVs 742 This section defines new LSAs and TLVs for both OSPFv2 and OSPFv3. 744 Following objects are added: 746 1. A TLV that is used to advertise the preference for becoming Area 747 Leader. 749 2. A TLV that is used to indicate the support for Dynamic Flooding 750 and the algorithms that the advertising node supports for 751 distributed mode, if any. 753 3. OSPFv2 Opaque LSA and OSPFv3 LSA to advertise the flooding 754 topology for centralized mode. 756 4. A TLV to carry the list of system IDs that compromise the 757 flooding topology for the area. 759 5. A TLV to carry a path which is part of the flooding topology. 761 6. The bit in the LLS Type 1 Extended Options and Flags requests 762 flooding from the adjacent node. 764 5.2.1. OSPF Area Leader Sub-TLV 766 The usage of the OSPF Area Leader Sub-TLV is identical to IS-IS and 767 is described in Section 5.1.1. 769 The OSPF Area Leader Sub-TLV is used by both OSPFv2 and OSPFv3. 771 The OSPF Area Leader Sub-TLV is advertised as a top-level TLV of the 772 RI LSA that is defined in [RFC7770] and has the following format: 774 0 1 2 3 775 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 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Type | Length | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Priority | Algorithm | Reserved | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 Type: TBD4 784 Length: 4 octets 786 Priority: 0-255, unsigned integer 788 Algorithm: as defined in Section 5.1.1. 790 5.2.2. OSPF Dynamic Flooding Sub-TLV 792 The usage of the OSPF Dynamic Flooding Sub-TLV is identical to IS-IS 793 and is described in Section 5.1.2. 795 The OSPF Dynamic Flooding Sub-TLV is used by both OSPFv2 and OSPFv3. 797 The OSPF Dynamic Flooding Sub-TLV is advertised as a top-level TLV of 798 the RI LSA that is defined in [RFC7770] and has the following format: 800 0 1 2 3 801 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 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Type | Length | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Algorithm ... | | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 Type: TBD8 810 Length: number of Algorithms 812 Algorithm: as defined in Section 5.1.1. 814 5.2.3. OSPFv2 Dynamic Flooding Opaque LSA 816 The OSPFv2 Dynamic Flooding Opaque LSA is only used in centralized 817 mode. 819 The OSPFv2 Dynamic Flooding Opaque LSA is used to advertise 820 additional data related to the dynamic flooding in OSPFv2. OSPFv2 821 Opaque LSAs are described in [RFC5250]. 823 Multiple OSPFv2 Dynamic Flooding Opaque LSAs can be advertised by an 824 OSPFv2 router. The flooding scope of the OSPFv2 Dynamic Flooding 825 Opaque LSA is area-local. 827 The format of the OSPFv2 Dynamic Flooding Opaque LSA is as follows: 829 0 1 2 3 830 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 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | LS age | Options | LS Type | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | TBD5 | Opaque ID | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Advertising Router | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | LS sequence number | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | LS checksum | Length | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | | 843 +- TLVs -+ 844 | ... | 846 OSPFv2 Dynamic Flooding Opaque LSA 848 The opaque type used by OSPFv2 Dynamic Flooding Opaque LSA is TBD. 849 The opaque type is used to differentiate the various type of OSPFv2 850 Opaque LSAs and is described in section 3 of [RFC5250]. The LS Type 851 is 10. The LSA Length field [RFC2328] represents the total length 852 (in octets) of the Opaque LSA including the LSA header and all TLVs 853 (including padding). 855 The Opaque ID field is an arbitrary value used to maintain multiple 856 Dynamic Flooding Opaque LSAs. For OSPFv2 Dynamic Flooding Opaque 857 LSAs, the Opaque ID has no semantic significance other than to 858 differentiate Dynamic Flooding Opaque LSAs originated by the same 859 OSPFv2 router. 861 The format of the TLVs within the body of the OSPFv2 Dynamic Flooding 862 Opaque LSA is the same as the format used by the Traffic Engineering 863 Extensions to OSPF [RFC3630]. 865 The Length field defines the length of the value portion in octets 866 (thus a TLV with no value portion would have a length of 0). The TLV 867 is padded to 4-octet alignment; padding is not included in the length 868 field (so a 3-octet value would have a length of 3, but the total 869 size of the TLV would be 8 octets). Nested TLVs are also 32-bit 870 aligned. For example, a 1-octet value would have the length field 871 set to 1, and 3 octets of padding would be added to the end of the 872 value portion of the TLV. The padding is composed of zeros. 874 5.2.4. OSPFv3 Dynamic Flooding LSA 876 The OSPFv3 Dynamic Flooding Opaque LSA is only used in centralized 877 mode. 879 The OSPFv3 Dynamic Flooding LSA is used to advertise additional data 880 related to the dynamic flooding in OSPFv3. 882 The OSPFv3 Dynamic Flooding LSA has a function code of TBD. The 883 flooding scope of the OSPFv3 Dynamic Flooding LSA is area-local. The 884 U bit will be set indicating that the OSPFv3 Dynamic Flooding LSA 885 should be flooded even if it is not understood. The Link State ID 886 (LSID) value for this LSA is the Instance ID. OSPFv3 routers MAY 887 advertise multiple Dynamic Flooding Opaque LSAs in each area. 889 The format of the OSPFv3 Dynamic Flooding LSA is as follows: 891 0 1 2 3 892 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 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | LS age |1|0|1| TBD6 | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Link State ID | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Advertising Router | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | LS sequence number | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | LS checksum | Length | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | | 905 +- TLVs -+ 906 | ... | 908 OSPFv3 Dynamic Flooding LSA 910 5.2.5. OSPF Area Router IDs TLV 912 The OSPF Area Router IDs TLV is a top level TLV of the OSPFv2 Dynamic 913 Flooding Opaque LSA and OSPFv3 Dynamic Flooding LSA. 915 The OSPF Area Router IDs TLV is used by the Area Leader to enumerate 916 the Router IDs that it has used in computing the flooding topology. 917 Conceptually, the Area Leader creates a list of Router IDs for all 918 routers in the area, assigning indices to each router, starting with 919 index 0. 921 Because the space in a single OSPF Area Router IDs TLV is limited, 922 more than one TLV may be required to encode all of the Router IDs in 923 the area. This TLV may also recur in multiple OSPFv2 Dynamic 924 Flooding Opaque LSAs or OSPFv3 Dynamic Flooding LSA, so that all 925 Router IDs can be advertised. 927 The format of the Area Router IDs TLV is: 929 0 1 2 3 930 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 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | Type | Length | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Starting Index |L| Flags | Reserved | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | | 937 +- Router IDs -+ 938 | ... | 940 OSPF Area Router IDs TLV 942 TLV Type: 1 944 TLV Length: 4 + (Router ID length * (number of Router IDs)) 946 Starting index: The index of the first Router ID that appears in 947 this TLV. 949 L (Last): This bit is set if the index of the last system ID that 950 appears in this TLV is equal to the last index in the full list of 951 Rourer IDs for the area. 953 Router IDs: A concatenated list of Router IDs for the area. 955 If there are multiple OSPF Area Router IDs TLVs with the L bit set 956 advertised by the same router, the TLV which specifies the smaller 957 maximum index is used and the other TLV(s) with L bit set are 958 ignored. TLVs which specify Router IDs with indices greater than 959 that specified by the TLV with the L bit set are also ignored. 961 5.2.6. OSPF Flooding Path TLV 963 The OSPF Flooding Path TLV is a top level TLV of the OSPFv2 Dynamic 964 Flooding Opaque LSAs and OSPFv3 Dynamic Flooding LSA. 966 The usage of the OSPF Flooding Path TLV is identical to IS-IS and is 967 described in Section 5.1.4. 969 The OSPF Flooding Path TLV contains a list of Router ID indices 970 relative to the Router IDs advertised through the OSPF Area Router 971 IDs TLV. At least 2 indices must be included in the TLV. 973 Multiple OSPF Flooding Path TLVs can be advertised in a single OSPFv2 974 Dynamic Flooding Opaque LSA or OSPFv3 Dynamic Flooding LSA. OSPF 975 Flooding Path TLVs can also be advertised in multiple OSPFv2 Dynamic 976 Flooding Opaque LSAs or OSPFv3 Dynamic Flooding LSA, if they all can 977 not fit in a single LSA. 979 The Flooding Path TLV has the format: 981 0 1 2 3 982 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 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Type | Length | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Starting Index | Index 2 | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | | 989 +- Additional Indices -+ 990 | ... | 992 OSPF Flooding Path TLV 994 TLV Type: 2 996 TLV Length: 2 * (number of indices in the path) 998 Starting index: The index of the first Router ID in the path. 1000 Index 2: The index of the next Router ID in the path. 1002 Additional indices (optional): A sequence of additional indices to 1003 Router IDs along the path. 1005 5.2.7. OSPF Flooding Request Bit 1007 A single new option bit, the Flooding-Request (FR-bit), is defined in 1008 the LLS Type 1 Extended Options and Flags field [RFC2328]. The FR- 1009 bit allows a router to request an adjacent node to enable flooding 1010 towards it on a specific link in the case where the connection to 1011 adjacent node is not part of the current flooding topology. 1013 Nodes that support Dynamic Flooding MAY include FR-bit in its OSPF 1014 LLS Extended Options and Flags TLV. 1016 If FR-bit is signalled for an area for which the flooding on the link 1017 was disabled due to Dynamic Flooding, the flooding MUST be 1018 temporarily enabled over such link and area. Flooding MUST be 1019 enabled until FR-bit is no longer advertised in the OSPF LLS Extended 1020 Options and Flags TLV or the OSPF LLS Extended Options and Flags TLV 1021 no longer appears in the OSPF Hellos. 1023 When the flooding is temporarily enabled on the link for any area due 1024 to received FR-bit in OSPF LLS Extended Options and Flags TLV, the 1025 receiver MUST perform standard database synchronization for the 1026 corresponding area(s) on the link. If the adjacency is already in 1027 the FULL state, mechanism specified in [RFC4811] MUST be used for 1028 database resynchronization. 1030 So long as the FR-bit is being received in the OSPF LLS Extended 1031 Options and Flags TLV for an area, flooding MUST not be disabled in 1032 such area even if the connection between the neighbors is removed 1033 from the flooding topology. Flooding for such area MUST continue on 1034 the link and be considered as temporarily enabled. 1036 6. Behavioral Specification 1038 In this section, we specify the detailed behaviors of the nodes 1039 participating in the IGP. 1041 6.1. Terminology 1043 We define some terminology here that is used in the following 1044 sections: 1046 A node is considered reachable if it is part of the connected 1047 network graph. Note that this is independent of any constraints 1048 which may be considered when performing IGP SPT calculation (e.g., 1049 link metrics, OL bit state, etc.). Two-way-connectivity check 1050 MUST be performed before including an edge in the connected 1051 network graph. 1053 Node is connected to the flooding topology, if it has at least one 1054 local link, which is part of the flooding topology. 1056 Node is disconnected from the flooding topology when it is not 1057 connected to the flooding topology. 1059 Current flooding topology - latest version of the flooding 1060 topology received (in case of the centralized mode) or calculated 1061 locally (in case of the distributed mode). 1063 6.2. Flooding Topology 1065 The flooding topology MUST include all reachable nodes in the area. 1067 If a node's reachability changes, the flooding topology MUST be 1068 recalculated. In centralized mode, the Area Leader MUST advertise a 1069 new flooding topology. 1071 If a node becomes disconnected from the current flooding topology but 1072 is still reachable then a new flooding topology MUST be calculated. 1073 In centralized mode the Area Leader MUST advertise the new flooding 1074 topology. 1076 The flooding topology SHOULD be bi-connected. 1078 6.3. Leader Election 1080 Any node that is capable MAY advertise its eligibility to become Area 1081 Leader. 1083 Nodes that are not reachable are not eligible as Area Leader. Nodes 1084 that do not advertise their eligibility to become Area Leader are not 1085 eligible. Amongst the eligible nodes, the node with the numerically 1086 highest priority is the Area Leader. If multiple nodes all have the 1087 highest priority, then the node with the numerically highest system 1088 identifier in the case of IS-IS, or Router-ID in the case of OSPFv2 1089 and OSPFv3 is the Area Leader. 1091 6.4. Area Leader Responsibilities 1093 If the Area Leader operates in centralized mode, it MUST advertise 1094 algorithm 0 in its Area Leader Sub-TLV. It also MUST compute and 1095 advertise a flooding topology for the area. The Area Leader may 1096 update the flooding topology at any time, however, it should not 1097 destabilize the network with undue or overly frequent topology 1098 changes. 1100 If the Area Leader operates in centralized mode and needs to 1101 advertises a new flooding topology, it floods a new flooding topology 1102 on both the new and old flooding topologies. 1104 6.5. Distributed Flooding Topology Calculation 1106 If the Area Leader advertises a non-zero algorithm in its Area Leader 1107 Sub-TLV, all nodes in the area that support Dynamic Flooding and the 1108 value of algorithm advertised by the Area Leader MUST compute the 1109 flooding topology based on the Area Leader's advertised algorithm. 1111 Nodes that do not support the value of algorithm advertised by the 1112 Area Leader MUST continue to use standard flooding mechanism as 1113 defined by the protocol. 1115 Nodes that do not support the value of algorithm advertised by the 1116 Area Leader MUST be considered as Dynamic Flooding incapable nodes by 1117 the Area Leader. 1119 If the value of the algorithm advertised by the Area Leader is from 1120 the range 128-254 (private distributed algorithms), it is the 1121 responsibility of the network operator to guarantee that all nodes in 1122 the area have a common understanding of what the given algorithm 1123 value represents. 1125 6.6. Flooding Behavior 1127 Nodes that support Dynamic Flooding MUST use the flooding topology 1128 for flooding when possible, and MUST NOT revert to standard flooding 1129 when a valid flooding topology is available. 1131 In some cases a node that supports Dynamic Flooding may need to add a 1132 local link(s) to the flooding topology temporarily, even though the 1133 link(s) is not part of the calculated flooding topology. This is 1134 termed "temporary flooding" and is discussed in Section 6.7.1. 1136 The flooding topology is calculated locally in the case of 1137 distributed mode. In centralized mode the flooding topology is 1138 advertised in the area link state database. Received link state 1139 updates, whether received on a link that is in the flooding topology 1140 or on a link that is not in the flooding topology, MUST be flooded on 1141 all links that are in the flooding topology, except for the link on 1142 which the update was received. 1144 In centralized mode, if multiple flooding topologies are present in 1145 the area link state database, the node SHOULD flood on the on each of 1146 these topologies. 1148 When the flooding topology changes on a node, either as a result of 1149 the local computation in distributed mode or as a result of the 1150 advertisement from the Area Leader in centralized mode, the node MUST 1151 continue to flood on both the old and new flooding topology for a 1152 limited amount of time. This is required to provide all nodes 1153 sufficient time to migrate to the new flooding topology. 1155 6.7. Treatment of Topology Events 1157 In this section, we explicitly consider a variety of different 1158 topological events in the network and how Dynamic Flooding should 1159 address them. 1161 6.7.1. Temporary Addition of Link to Flooding Topology 1163 In some cases a node that supports Dynamic Flooding may need to add a 1164 local link(s) to the flooding topology temporarily, even though the 1165 link(s) is not part of the calculated flooding topology. We refer to 1166 this as "temporary flooding" on the link. 1168 When temporary flooding is enabled on the link, the flooding needs to 1169 be enabled from both directions on such link. To achieve that, the 1170 following steps MUST be performed: 1172 Link State Database needs to be re-synchronised on the link. This 1173 is done using the standard protocol mechanisms. In the case of 1174 IS-IS, this results in setting SRM bit for all LSPs on the circuit 1175 and sending compete set of CSNPs on it. In OSPF, the mechanism 1176 specified in [RFC4811] is used. 1178 Flooding is enabled locally on the link. 1180 Flooding is requested from the neighbor using the mechanism 1181 specified in section Section 5.1.5 or Section 5.2.7. 1183 The request for temporary flooding is withdrawn on the link when all 1184 of the following conditions are met: 1186 Node itself is connected to the current flooding topology. 1188 Adjacent node is connected to the current flooding topology. 1190 Any change in the flooding topology MUST result in evaluation of the 1191 above conditions for any link on which the temporary flooding was 1192 enabled. 1194 Temporary flooding is stopped on the link when both adjacent nodes 1195 stop requesting temporary flooding on the link. 1197 6.7.2. Local Link Addition 1199 If a local link is added to the topology, the protocol will form a 1200 normal adjacency on the link and update the appropriate link state 1201 advertisements for the nodes on either end of the link. These link 1202 state updates will be flooded on the flooding topology. 1204 In centralized mode, the Area Leader, upon receiving these updates, 1205 may choose to retain the existing flooding topology or may choose to 1206 modify the flooding topology. If it elects to change the flooding 1207 topology, it will update the flooding topology in the link state 1208 database and flood it using the new flooding topology. 1210 In distributed mode, any change in the topology, including the link 1211 addition, MUST trigger the flooding topology recalculation. This is 1212 done to ensure that all nodes converge to the same flooding topology, 1213 regardless of the time of the calculation. 1215 Temporary flooding MUST be enabled on the newly added local link, if 1216 at least one of the following conditions are met: 1218 The node on which the local link was added is not connected to the 1219 current flooding topology. 1221 The new adjacent node is not connected to the current flooding 1222 topology. 1224 Note that in this case there is no need to perform a database 1225 synchronization as part of the enablement of the temporary flooding, 1226 because it has been part of the adjacency bring-up itself. 1228 If multiple local links are added to the topology before the flooding 1229 topology is updated, temporary flooding MUST be enabled on a subset 1230 of these links. 1232 6.7.3. Node Addition 1234 If a node is added to the topology, then at least one link is also 1235 added to the topology. Section 6.7.2 applies. 1237 6.7.4. Failures of Link Not on Flooding Topology 1239 If a link that is not part of the flooding topology fails, then the 1240 adjacent nodes will update their link state advertisements and flood 1241 them on the flooding topology. 1243 In centralized mode, the Area Leader, upon receiving these updates, 1244 may choose to retain the existing flooding topology or may choose to 1245 modify the flooding topology. If it elects to change the flooding 1246 topology, it will update the flooding topology in the link state 1247 database and flood it using the new flooding topology. 1249 In distributed mode, any change in the topology, including the 1250 failure of the link that is not part of the flooding topology MUST 1251 trigger the flooding topology recalculation. This is done to ensure 1252 that all nodes converge to the same flooding topology, regardless of 1253 the time of the calculation. 1255 6.7.5. Failures of Link On the Flooding Topology 1257 If there is a failure on the flooding topology, the adjacent nodes 1258 will update their link state advertisements and flood them. If the 1259 original flooding topology is bi-connected, the flooding topology 1260 should still be connected despite a single failure. 1262 If the failed local link represented the only connection to the 1263 flooding topology on the node where the link failed, the node MUST 1264 enable temporary flooding on a subset of its local links. This 1265 allows the node to send its updated link state advertisement(s) and 1266 also keep receiving link state updates from other nodes in the 1267 network before the new flooding topology is calculated and 1268 distributed (in the case of centralized mode). 1270 In centralized mode, the Area Leader will notice the change in the 1271 flooding topology, recompute the flooding topology, and flood it 1272 using the new flooding topology. 1274 In distributed mode, all nodes supporting dynamic flooding will 1275 notice the change in the topology and recompute the new flooding 1276 topology. 1278 6.7.6. Node Deletion 1280 If a node is deleted from the topology, then at least one link is 1281 also removed from the topology. The two sections above apply. 1283 6.7.7. Local Link Addition to the Flooding Topology 1285 If the new flooding topology is received in the case of centralized 1286 mode, or calculated locally in the case of distributed mode and the 1287 local link on the node that was not part of the flooding topology has 1288 been added to the flooding topology, the node MUST: 1290 Re-synchronize the Link State Database over the link. This is 1291 done using the standard protocol mechanisms. In the case of IS- 1292 IS, this results in setting SRM bit for all LSPs on the circuit 1293 and sending a complete set of CSNPs. In OSPF, the mechanism 1294 specified in [RFC4811] is used. 1296 Make the link part of the flooding topology and start flooding 1297 over it 1299 6.7.8. Local Link Deletion from the Flooding Topology 1301 If the new flooding topology is received in the case of centralized 1302 mode, or calculated locally in the case of distributed mode and the 1303 local link on the node that was part of the flooding topology has 1304 been removed from the flooding topology, the node MUST remove the 1305 link from the flooding topology. 1307 The node MUST keep flooding on such link for a limited amount of time 1308 to allow other nodes to migrate to the new flooding topology. 1310 If the removed local link represented the only connection to the 1311 flooding topology on the node, the node MUST enable temporary 1312 flooding on a subset of its local links. This allows the node to 1313 send its updated link state advertisement(s) and also keep receiving 1314 link state updates from other nodes in the network before the new 1315 flooding topology is calculated and distributed (in the case of 1316 centralized mode). 1318 6.7.9. Treatment of Disconnected Adjacent Nodes 1320 Every time there is a change in the flooding topology a node MUST 1321 check if there are any adjacent nodes that are disconnected from the 1322 current flooding topology. Temporary flooding MUST be enabled 1323 towards a subset of the disconnected nodes. 1325 6.7.10. Failure of the Area Leader 1327 The failure of the Area Leader can be detected by observing that it 1328 is no longer reachable. In this case, the Area Leader election 1329 process is repeated and a new Area Leader is elected. 1331 In the centralized mode, the new Area Leader will compute a new 1332 flooding topology and flood it using the new flooding topology. 1334 As an optimization, applicable to centralized mode, the new Area 1335 Leader MAY compute a new flooding topology that has as much in common 1336 as possible with the old flooding topology. This will minimize the 1337 risk of over-flooding. 1339 In the distributed mode, the new flooding topology will be calculated 1340 on all nodes that support the algorithm that is advertised by the new 1341 Area Leader. Nodes that do not support the algorithm advertised by 1342 the new Area Leader will no longer participate in Dynamic Flooding 1343 and will revert to standard flooding. 1345 6.7.11. Recovery from Multiple Failures 1347 In the unlikely event of multiple failures on the flooding topology, 1348 it may become partitioned. The nodes that remain active on the edges 1349 of the flooding topology partitions will recognize this and will try 1350 to repair the flooding topology locally by enabling temporary 1351 flooding towards the nodes that they consider disconnected from the 1352 flooding topology until a new flooding topology becomes connected 1353 again. 1355 Nodes where local failure was detected update their own link state 1356 advertisements and flood them on the remainder of the flooding 1357 topology. 1359 In centralized mode, the Area Leader will notice the change in the 1360 flooding topology, recompute the flooding topology, and flood it 1361 using the new flooding topology. 1363 In distributed mode, all nodes that actively participate in Dynamic 1364 Flooding will compute the new flooding topology. 1366 Note that this is very different from the area partition because 1367 there is still a connected network graph between the nodes in the 1368 area. The area may remain connected and forwarding may still be 1369 effective. 1371 7. IANA Considerations 1373 7.1. IS-IS 1375 This document requests the following code point from the "sub-TLVs 1376 for TLV 242" registry (IS-IS Router CAPABILITY TLV). 1378 Type: TBD1 1380 Description: IS-IS Area Leader Sub-TLV 1382 Reference: This document (Section 5.1.1) 1384 Type: TBD7 1386 Description: IS-IS Dynamic Flooding Sub-TLV 1388 Reference: This document (Section 5.1.2) 1390 This document requests that IANA allocate and assign two code points 1391 from the "IS-IS TLV Codepoints" registry. One for each of the 1392 following TLVs: 1394 Type: TBD2 1396 Description: IS-IS Area System IDs TLV 1398 Reference: This document (Section 5.1.3) 1400 Type: TBD3 1402 Description: IS-IS Flooding Path TLV 1404 Reference: This document (Section 5.1.4) 1406 Type: TBD9 1408 Description: IS-IS Flooding Request TLV 1410 Reference: This document (Section 5.1.5) 1412 7.2. OSPF 1414 This document requests the following code points from the "OSPF 1415 Router Information (RI) TLVs" registry: 1417 Type: TBD4 1419 Description: OSPF Area Leader Sub-TLV 1421 Reference: This document (Section 5.2.1) 1423 Type: TBD8 1425 Description: OSPF Dynamic Flooding Sub-TLV 1427 Reference: This document (Section 5.2.2) 1429 This document requests the following code point from the "Opaque 1430 Link-State Advertisements (LSA) Option Types" registry: 1432 Type: TBD5 1434 Description: OSPFv2 Dynamic Flooding Opaque LSA 1436 Reference: This document (Section 5.2.3) 1438 This document requests the following code point from the "OSPFv3 LSA 1439 Function Codes" registry: 1441 Type: TBD6 1442 Description: OSPFv3 Dynamic Flooding LSA 1444 Reference: This document (Section 5.2.4) 1446 This document requests a new bit in LLS Type 1 Extended Options and 1447 Flags registry: 1449 Bit Position: TBD10 1451 Description: Flooding Request bit 1453 Reference: This document (Section 5.2.7) 1455 7.2.1. OSPF Dynamic Flooding LSA TLVs Registry 1457 This specification also requests one new registry - "OSPF Dynamic 1458 Flooding LSA TLVs". New values can be allocated via IETF Review or 1459 IESG Approval 1461 The "OSPF Dynamic Flooding LSA TLVs" registry will define top-level 1462 TLVs for the OSPFv2 Dynamic Flooding Opaque LSA and OSPFv3 Dynamic 1463 Flooding LSAs. It should be added to the "Open Shortest Path First 1464 (OSPF) Parameters" registries group. 1466 The following initial values are allocated: 1468 Type: 0 1470 Description: Reserved 1472 Reference: This document 1474 Type: 1 1476 Description: OSPF Area Router IDs TLV 1478 Reference: This document (Section 5.2.5) 1480 Type: 2 1482 Description: OSPF Flooding Path TLV 1484 Reference: This document (Section 5.2.6) 1486 Types in the range 32768-33023 are for experimental use; these will 1487 not be registered with IANA, and MUST NOT be mentioned by RFCs. 1489 Types in the range 33024-65535 are not to be assigned at this time. 1490 Before any assignments can be made in the 33024-65535 range, there 1491 MUST be an IETF specification that specifies IANA Considerations that 1492 covers the range being assigned. 1494 7.3. IGP 1496 IANA is requested to set up a registry called "IGP Algorithm Type For 1497 Computing Flooding Topology" under an existing "Interior Gateway 1498 Protocol (IGP) Parameters" IANA registries. 1500 Values in this registry come from the range 0-255. 1502 The initial values in the IGP Algorithm Type For Computing Flooding 1503 Topology registry are: 1505 0: Reserved for centralized mode. Individual values are are to be 1506 assigned according to the "Specification Required" policy defined 1507 in [RFC8126] 1509 1-127: Available for standards action.Individual values are are to 1510 be assigned according to the "Private Use" policy defined in 1511 [RFC8126] 1513 128-254: Reserved for private use. 1515 255: Reserved. 1517 8. Security Considerations 1519 This document introduces no new security issues. Security of routing 1520 within a domain is already addressed as part of the routing protocols 1521 themselves. This document proposes no changes to those security 1522 architectures. 1524 It is possible that an attacker could become Area Leader and 1525 introduce a flawed flooding algorithm into the network thus 1526 compromising the operation of the protocol. Authentication methods 1527 as describe in [RFC5304] and [RFC5310] for IS-IS, [RFC2328] and 1528 [RFC7474] for OSPFv2 and [RFC5340] and [RFC4552] for OSPFv3 SHOULD be 1529 used to prevent such attack. 1531 9. Acknowledgements 1533 The authors would like to thank Sarah Chen for her contribution to 1534 this work. 1536 The authors would like to thank Zeqing (Fred) Xia, Naiming Shen, Adam 1537 Sweeney and Olufemi Komolafe for their helpful comments. 1539 The authors would like to thank Tom Edsall for initially introducing 1540 them to the problem. 1542 10. References 1544 10.1. Normative References 1546 [ISO10589] 1547 International Organization for Standardization, 1548 "Intermediate System to Intermediate System Intra-Domain 1549 Routing Exchange Protocol for use in Conjunction with the 1550 Protocol for Providing the Connectionless-mode Network 1551 Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 2002. 1553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1554 Requirement Levels", BCP 14, RFC 2119, 1555 DOI 10.17487/RFC2119, March 1997, 1556 . 1558 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1559 DOI 10.17487/RFC2328, April 1998, 1560 . 1562 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 1563 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 1564 . 1566 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1567 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 1568 July 2008, . 1570 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 1571 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 1572 2008, . 1574 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1575 and M. Fanto, "IS-IS Generic Cryptographic 1576 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 1577 2009, . 1579 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1580 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1581 . 1583 [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. 1584 Yeung, "OSPF Link-Local Signaling", RFC 5613, 1585 DOI 10.17487/RFC5613, August 2009, 1586 . 1588 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 1589 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 1590 2014, . 1592 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 1593 Scope Link State PDUs (LSPs)", RFC 7356, 1594 DOI 10.17487/RFC7356, September 2014, 1595 . 1597 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 1598 "Security Extension for OSPFv2 When Using Manual Key 1599 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 1600 . 1602 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1603 S. Shaffer, "Extensions to OSPF for Advertising Optional 1604 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 1605 February 2016, . 1607 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 1608 for Advertising Router Information", RFC 7981, 1609 DOI 10.17487/RFC7981, October 2016, 1610 . 1612 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1613 Writing an IANA Considerations Section in RFCs", BCP 26, 1614 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1615 . 1617 10.2. Informative References 1619 [Clos] Clos, C., "A Study of Non-Blocking Switching Networks", 1620 The Bell System Technical Journal Vol. 32(2), DOI 1621 10.1002/j.1538-7305.1953.tb01433.x, March 1953, 1622 . 1624 [Leiserson] 1625 Leiserson, C., "Fat-Trees: Universal Networks for 1626 Hardware-Efficient Supercomputing", IEEE Transactions on 1627 Computers 34(10):892-901, 1985. 1629 [RFC2973] Balay, R., Katz, D., and J. Parker, "IS-IS Mesh Groups", 1630 RFC 2973, DOI 10.17487/RFC2973, October 2000, 1631 . 1633 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1634 (TE) Extensions to OSPF Version 2", RFC 3630, 1635 DOI 10.17487/RFC3630, September 2003, 1636 . 1638 [RFC4811] Nguyen, L., Roy, A., and A. Zinin, "OSPF Out-of-Band Link 1639 State Database (LSDB) Resynchronization", RFC 4811, 1640 DOI 10.17487/RFC4811, March 2007, 1641 . 1643 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 1644 BGP for Routing in Large-Scale Data Centers", RFC 7938, 1645 DOI 10.17487/RFC7938, August 2016, 1646 . 1648 Authors' Addresses 1650 Tony Li (editor) 1651 Arista Networks 1652 5453 Great America Parkway 1653 Santa Clara, California 95054 1654 USA 1656 Email: tony.li@tony.li 1658 Peter Psenak (editor) 1659 Cisco Systems, Inc. 1660 Eurovea Centre, Central 3 1661 Pribinova Street 10 1662 Bratislava 81109 1663 Slovakia 1665 Email: ppsenak@cisco.com 1667 Les Ginsberg 1668 Cisco Systems, Inc. 1669 510 McCarthy Blvd. 1670 Milpitas, California 95035 1671 USA 1673 Email: ginsberg@cisco.com 1674 Tony Przygienda 1675 Juniper Networks, Inc. 1676 1194 N. Mathilda Ave 1677 Sunnyvale, California 94089 1678 USA 1680 Email: prz@juniper.net 1682 Dave Cooper 1683 CenturyLink 1684 1025 Eldorado Blvd 1685 Broomfield, Colorado 80021 1686 USA 1688 Email: Dave.Cooper@centurylink.com 1690 Luay Jalil 1691 Verizon 1692 Richardson, Texas 75081 1693 USA 1695 Email: luay.jalil@verizon.com 1697 Srinath Dontula 1698 ATT 1699 200 S Laurel Ave 1700 Middletown, New Jersey 07748 1701 USA 1703 Email: sd947e@att.com