idnits 2.17.1 draft-cc-lsr-flooding-reduction-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1870 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: 'RFC5250' is defined on line 802, but no explicit reference was found in the text == Unused Reference: 'RFC5340' is defined on line 815, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 837, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-lsr-dynamic-flooding-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-lsr-dynamic-flooding (ref. 'I-D.ietf-lsr-dynamic-flooding') -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Chen 3 Internet-Draft D. Cheng 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 12, 2019 M. Toy 6 Verizon 7 Y. Yang 8 IBM 9 A. Wang 10 China Telecom 11 X. Liu 12 Volta Networks 13 Y. Fan 14 Casa Systems 15 L. Liu 16 March 11, 2019 18 LS Distributed Flooding Reduction 19 draft-cc-lsr-flooding-reduction-03 21 Abstract 23 This document proposes an approach to flood link states on a topology 24 that is a subgraph of the complete topology per underline physical 25 network, so that the amount of flooding traffic in the network is 26 greatly reduced, and it would reduce convergence time with a more 27 stable and optimized routing environment. The approach can be 28 applied to any network topology in a single area. In this approach, 29 every node in the area automatically calculates a flooding topology 30 by using a same algorithm concurrently. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on September 12, 2019. 55 Copyright Notice 57 Copyright (c) 2019 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Flooding Topology . . . . . . . . . . . . . . . . . . . . . . 4 75 3.1. Flooding Topology Construction . . . . . . . . . . . . . 4 76 3.2. Scheduling for Flooding Topology Computation . . . . . . 5 77 3.2.1. Scheduler with Exponential Delay . . . . . . . . . . 6 78 3.2.2. Scheduler with Constant Delay . . . . . . . . . . . . 6 79 3.3. Flooding Topology Consistency . . . . . . . . . . . . . . 7 80 3.4. Flooding Topology Protection . . . . . . . . . . . . . . 7 81 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 8 82 4.1. Extensions for Operations . . . . . . . . . . . . . . . . 8 83 4.1.1. Extensions to OSPF . . . . . . . . . . . . . . . . . 8 84 4.1.2. Extensions to IS-IS . . . . . . . . . . . . . . . . . 10 85 4.2. Extensions for Consistency . . . . . . . . . . . . . . . 11 86 4.2.1. Extensions to OSPF . . . . . . . . . . . . . . . . . 11 87 4.2.2. Extensions to IS-IS . . . . . . . . . . . . . . . . . 12 88 5. Flooding Behavior . . . . . . . . . . . . . . . . . . . . . . 12 89 5.1. Nodes Perform Flooding Reduction without Failure . . . . 13 90 5.1.1. Receiving an LS . . . . . . . . . . . . . . . . . . . 13 91 5.1.2. Originating an LS . . . . . . . . . . . . . . . . . . 13 92 5.1.3. Establishing Adjacencies . . . . . . . . . . . . . . 13 93 5.2. An Exception Case . . . . . . . . . . . . . . . . . . . . 14 94 5.2.1. Multiple Failures . . . . . . . . . . . . . . . . . . 14 95 5.2.2. Changes on Flooding Topology . . . . . . . . . . . . 14 97 6. Operations on Flooding Reduction . . . . . . . . . . . . . . 15 98 6.1. Configuring Flooding Reduction . . . . . . . . . . . . . 15 99 6.1.1. Configurations for Distributed Flooding Reduction . . 15 100 6.2. Migration to Flooding Reduction . . . . . . . . . . . . . 15 101 6.2.1. Migration to Distributed Flooding Reduction . . . . . 15 102 6.3. Roll Back to Normal Flooding . . . . . . . . . . . . . . 15 103 7. Manageability Considerations . . . . . . . . . . . . . . . . 16 104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 106 9.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 16 107 9.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 17 108 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 109 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 110 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 111 11.2. Informative References . . . . . . . . . . . . . . . . . 18 112 Appendix A. Algorithms to Build Flooding Topology . . . . . . . 19 113 A.1. Algorithms to Build Tree without Considering Others . . . 19 114 A.2. Algorithms to Build Tree Considering Others . . . . . . . 20 115 A.3. Connecting Leaves . . . . . . . . . . . . . . . . . . . . 22 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 118 1. Introduction 120 For some networks such as dense Data Center (DC) networks, the 121 existing Link State (LS) flooding mechanism is not efficient and may 122 have some issues. The extra LS flooding consumes network bandwidth. 123 Processing the extra LS flooding, including receiving, buffering and 124 decoding the extra LSs, wastes memory space and processor time. This 125 may cause scalability issues and affect the network convergence 126 negatively. 128 This document proposes an approach to minimize the amount of flooding 129 traffic in the network. Thus the workload for processing the extra 130 LS flooding is decreased significantly. This would improve the 131 scalability, speed up the network convergence, stable and optimize 132 the routing environment. 134 In this approach, every node in the network automatically calculates 135 a flooding topology by using a same algorithm concurrently at almost 136 the same time. It floods a link state on the flooding topology. 137 There may be multiple algorithms for computing a flooding topology. 138 Users can select one they prefer, and smoothly switch from one to 139 another. The approach is applicable to any network topology in a 140 single area. It is backward compatible. 142 2. Terminology 144 LSA: A Link State Advertisement in OSPF. 146 LSP: A Link State Protocol Data Unit (PDU) in IS-IS. 148 LS: A Link Sate, which is an LSA or LSP. 150 FTC: Flooding Topology Computation. 152 3. Flooding Topology 154 For a given network topology, a flooding topology is a sub-graph or 155 sub-network of the given network topology that has the same 156 reachability to every node as the given network topology. Thus all 157 the nodes in the given network topology MUST be in the flooding 158 topology. All the nodes MUST be inter-connected directly or 159 indirectly. As a result, LS flooding will in most cases occur only 160 on the flooding topology, that includes all nodes but a subset of 161 links. Note even though the flooding topology is a sub-graph of the 162 original topology, any single LS MUST still be disseminated in the 163 entire network. 165 3.1. Flooding Topology Construction 167 Many different flooding topologies can be constructed for a given 168 network topology. A chain connecting all the nodes in the given 169 network topology is a flooding topology. A circle connecting all the 170 nodes is another flooding topology. A tree connecting all the nodes 171 is a flooding topology. In addition, the tree plus the connections 172 between some leaves of the tree and branch nodes of the tree is a 173 flooding topology. 175 The following parameters need to be considered for constructing a 176 flooding topology: 178 o Number of links: The number of links on the flooding topology is a 179 key factor for reducing the amount of LS flooding. In general, 180 the smaller the number of links, the less the amount of LS 181 flooding. 183 o Diameter: The shortest distance between the two most distant nodes 184 on the flooding topology (i.e., the diameter of the flooding 185 topology) is a key factor for reducing the network convergence 186 time. The smaller the diameter, the less the convergence time. 188 o Redundancy: The redundancy of the flooding topology means a 189 tolerance to the failures of some links and nodes on the flooding 190 topology. If the flooding topology is split by some failures, it 191 is not tolerant to these failures. In general, the larger the 192 number of links on the flooding topology is, the more tolerant the 193 flooding topology to failures. 195 There are three different ways to construct a flooding topology for a 196 given network topology: centralized, distributed and static mode. 197 This document focuses on the distributed mode, in which each node in 198 the network automatically calculates a flooding topology by using a 199 same algorithm concurrently at almost the same time. 201 Note that the flooding topology constructed by a node is dynamic in 202 nature, that means when the base topology (the entire topology graph) 203 changes, the flooding topology (the sub-graph) MUST be re-computed/ 204 re-constructed to ensure that any node that is reachable on the base 205 topology MUST also be reachable on the flooding topology. 207 For reference purpose, some algorithms that allow nodes to 208 automatically compute flooding topology are elaborated in Appendix A. 209 However, this document does not attempt to standardize how a flooding 210 topology is established. 212 3.2. Scheduling for Flooding Topology Computation 214 In a network consisting of routers from multiple vendors, there are 215 different schedulers for SPF. Using different schedulers is in favor 216 of creating more micro routing loops during the convergence process 217 due to discrepancies of schedulers than using a same scheduler. More 218 micro routing loops will lead to more traffic lose. Service 219 providers are already aware to use similar timers (values and 220 behavior), but sometimes it is not possible due to limitations of 221 schedulers [I-D.ietf-rtgwg-spf-uloop-pb-statement]. In order to let 222 every node run a flooding topology computation (FTC) at almost the 223 same time, we need to have a same scheduler for FTC to be implemented 224 by multiple vendors. 226 Two schedulers are described below. One uses a constant delay such 227 as 200ms for each of multiple consecutive FTCs. For example, for 228 four consecutive FTCs, the second FTC will be triggered 200ms after 229 the first FTC; the third FTC will be triggered 200ms after the second 230 FTC; and the forth FTC will be triggered 200ms after the third FTC. 232 The other uses an exponential delay starting from a given hold time 233 such as 100ms for consecutive FTCs. For example, for four 234 consecutive FTCs, the second FTC will be triggered 2 x 100ms = 200ms 235 after the first FTC; the third FTC will be triggered 2 x 200ms = 236 400ms after the second FTC; and the forth FTC will be triggered 2 x 237 400ms = 800ms after the second FTC. 239 If these two schedulers are used in a network, it is almost 240 impossible to let every node in the network run FTC at almost same 241 time for multiple consecutive FTCs. 243 3.2.1. Scheduler with Exponential Delay 245 There are three parameters for the scheduler: initial-delay, minimum- 246 hold-time and maximum-wait-time. The initial-delay is the delay in 247 milliseconds from detecting a topology change to triggering FTC. Its 248 default value is 50ms. 250 The minimum-hold-time is the minimum hold time in milliseconds 251 between two consecutive FTCs. Its default value is 100ms. 253 The maximum-wait-time is the maximum wait time in milliseconds for 254 triggering FTC. Its default value is 2000ms. 256 The behavior of the scheduler with these parameters is described as 257 follows: 259 1. When FTC is to be called first time, initial-delay for FTC. 260 2. When FTC is to be called n-th (n > 1) time consecutively, 261 delay T = minimum-hold-time x 2^(n-2) for FTC if T is less 262 than maximum-wait-time 263 3. When T = hold-time x 2^(n-2) reaches maximum-wait-time, 264 delay maximum-wait-time for FTC. Then repeats step 1 265 (i.e., the next FTC call is considered as first time again). 267 Scheduler with Exponential Delay 269 3.2.2. Scheduler with Constant Delay 271 There are three parameters for the scheduler: constant-delay, number- 272 of-runs and maximum-wait-time. The constant-delay is the constant 273 time to delay in milliseconds from detecting a topology change to 274 triggering FTC. Its default value is 200ms. 276 The number-of-runs is the maximum number of times that FTC can run 277 consecutively. Its default value is 5. 279 The maximum-wait-time is the maximum wait time in milliseconds for 280 triggering FTC. Its default value is 2000ms. 282 The behavior of the scheduler with these parameters is described as 283 follows: 285 1. When FTC is to be called first time, constant-delay for FTC. 286 2. When FTC is to be called n-th (n > 1) time consecutively, 287 delay constant-delay for FTC if n <= number-of-runs 288 3. If n == number-of-runs, 289 delay maximum-wait-time, and then repeats step 1 290 (i.e., the next FTC call is considered as first time again). 292 Scheduler with Constant Delay 294 3.3. Flooding Topology Consistency 296 The flooding topology computed by one node needs to be the same as 297 the one computed by another node. When two flooding topologies 298 computed by two nodes are different, this inconsistency needs to be 299 detected and handled accordingly. 301 3.4. Flooding Topology Protection 303 It is hard to construct a flooding topology that reduces the amount 304 of LS flooding greatly and is tolerant to multiple failures. Without 305 any protection against a flooding topology split when multiple 306 failures on the flooding topology happen, we may have a slow 307 convergence. It is better to have some simple and fast methods for 308 protecting the flooding topology split. Thus the convergence is not 309 slowed down. 311 In one way, when two or more failures on the current flooding 312 topology occur almost in the same time, each of the nodes within a 313 given distance (such as 3 hops) to a failure point, floods the link 314 state (LS) that it receives to all the links (except for the one from 315 which the LS is received) until a new flooding topology is built. 317 In other words, when the failures happen, each of the nodes within a 318 given distance to a failure point, adds all its local links to the 319 flooding topology temporarily until a new flooding topology is built. 321 In another way, each node computes and maintains a small number of 322 backup paths. For a backup path for a link L on the flooding 323 topology, a node N computes and maintains it only if the backup path 324 goes through node N. Node N stores the links (e.g., local link L1 325 and L2) attached to it and on the backup path. When link L fails and 326 there are one or more failures on the flooding topology (and 327 additionally the number of nodes collected through traversing the 328 flooding topology is less than the number of live nodes in the area), 329 node N adds the links (e.g., L1 and L2) to the flooding topology 330 temporarily until a new flooding topology is built. Note that 331 checking the additional condition will slow down the convergence when 332 the flooding topology is split. It is optional. 334 Suppose that the two end nodes of link L is A and B, and A's ID is 335 smaller than B's. Node N computes a path from A to B with minimum 336 hops and whose links are not on the flooding topology. This path is 337 a backup path for link L. A backup path can be computed before link 338 L fails or computed after link L fails and there is a need for it. 339 Using the former will make the convergence time shorter. For the 340 former, when the pre-computed backup path is broken because of 341 failures, a new backup path needs to be computed. 343 Similarly, for a backup path for a connection crossing a node M on 344 the flooding topology, a node N computes and maintains it only if the 345 backup path goes through node N. Node N stores the links (e.g., 346 local link La and Lb) attached to it and on the backup path for node 347 M. 349 4. Protocol Extensions 351 The extensions comprises two parts: one part is for operations on 352 flooding reduction, the other is for flooding topology consistency. 354 4.1. Extensions for Operations 356 4.1.1. Extensions to OSPF 358 The OSPF Dynamic Flooding sub-TLV and area leader sub-TLV are defined 359 in [I-D.ietf-lsr-dynamic-flooding]. The former may contains a number 360 of algorithms. The latter contains instructions about flooding 361 reduction. 363 Every node supporting the distributed flooding reduction MUST 364 indicate its algorithms for flooding topology computation in a OSPF 365 Dynamic Flooding sub-TLV. This sub-TLV in a RI LSA will be 366 advertised to the area leader. 368 When the distributed flooding reduction is selected, every node MUST 369 receive the OSPF area leader sub-TLV in a RI LSA from the area 370 leader, which indicates the distributed mode and an algorithm to be 371 used. It SHOULD receive the parameters needed for the algorithm and 372 the distributed mode. 374 The parameters for the distributed mode include those three 375 parameters configured for the scheduler for flooding topology 376 computation. Through configuring these parameters on one place such 377 as the area leader and automatically advertising them to every node 378 in the network, we simplify the operation on flooding reduction and 379 reduce the errors on configurations (comparing to manually 380 configuring these parameters on every node). 382 A new sub-TLV, called OSPF Scheduler Parameters sub-TLV, is defined 383 for advertising the three parameters configured for the scheduler. 384 Its format is illustrated below. 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Type (TBD1) | Length (8) | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | initial-delay | minimum-hold-time | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | maximum-wait-time | Reserved (MUST be zero) | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 OSPF Scheduler Parameters sub-TLV 398 Type: TBD1 for Scheduler Parameters is to be assigned by IANA. 400 Length: 8. 402 initial-delay: 2 octets' field representing the initial delay in 403 milliseconds. 405 minimum-hold-time: 2 octets' field representing the minimum hold 406 time in milliseconds. 408 maximum-wait-time: 2 octets' field representing the maximum wait 409 time in milliseconds. 411 Reserved: MUST be set to 0 while sending and ignored on receipt. 413 In the case where the distributed flooding reduction is selected and 414 an algorithm for flooding topology computation is given already, 415 there are some operational changes. These changes include: 417 1 the algorithm given is changed to another algorithm; 419 2 the distributed flooding reduction is rolled back to normal 420 flooding; and 422 3 the distributed flooding reduction is changed to centralized 423 flooding reduction. 425 For the first change, every node MUST receive the OSPF area leader 426 sub-TLV in a RI LSA from the leader, which indicates that another 427 algorithm is to be used. After receiving the sub-TLV, it uses the 428 new algorithm to compute a new flooding topology, and floods link 429 states over both the flooding topology computed by the old algorithm 430 and the new flooding topology for a given time. And then it will 431 floods link states over the flooding topology computed by the new 432 algorithm. 434 For the second change, every node MUST receive the OSPF area leader 435 sub-TLV in a RI LSA from the leader, which indicates the current 436 flooding reduction is to be rolled back to normal flooding. After 437 receiving the sub-TLV, it stops computing flooding topology and 438 flooding link states over a flooding topology. It floods link states 439 using all its local links instead of the local links on the flooding 440 topology. 442 Note that the OSPF area leader sub-TLV defined in 443 [I-D.ietf-lsr-dynamic-flooding] needs to be extended to allow users 444 to roll back to normal flooding. The Flooding Reduction Instruction 445 sub-TLV defined in version 01 of this draft supports this. 447 4.1.2. Extensions to IS-IS 449 Similar to OSPF, the IS-IS Dynamic Flooding sub-TLV and area leader 450 sub-TLV are also defined in [I-D.ietf-lsr-dynamic-flooding]. 452 Every node supporting the distributed flooding reduction MUST 453 indicate its algorithms for flooding topology computation in an IS-IS 454 Dynamic Flooding sub-TLV in an LSP to be advertised to the leader. 456 When the distributed flooding reduction is selected, every node MUST 457 receive the IS-IS area leader sub-TLV in an LSP, which indicates the 458 distributed mode and an algorithm to be used. It SHOULD receive the 459 parameters needed for the algorithm and the distributed mode. 461 A new sub-TLV, called IS-IS Scheduler Parameters sub-TLV, is defined 462 for advertising the three parameters configured for the scheduler. 463 Its format is illustrated below. 465 0 1 2 3 466 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 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Type (TBD2) | Length (8) | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | initial-delay | minimum-hold-time | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | maximum-wait-time | Reserved (MUST be zero) | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 IS-IS Scheduler Parameters sub-TLV 477 Type: TBD1 for Scheduler Parameters is to be assigned by IANA. 479 Length: 8. 481 initial-delay: 2 octets' field representing the initial delay in 482 milliseconds. 484 minimum-hold-time: 2 octets' field representing the minimum hold 485 time in milliseconds. 487 maximum-wait-time: 2 octets' field representing the maximum wait 488 time in milliseconds. 490 Reserved: MUST be set to 0 while sending and ignored on receipt. 492 4.2. Extensions for Consistency 494 4.2.1. Extensions to OSPF 496 RFC 5613 defines a TLV called Extended Options and Flag (EOF) TLV. A 497 OSPF Hello may contain this TLV in link-local signaling (LLS) data 498 block. A new flag bit (bit 30 suggested), called link on flooding 499 topology (FT-bit for short), is defined in EOF TLV. 501 When a node B receives a Hello from its adjacent node A over a link, 502 FT-bit set to one in the Hello indicates that the link is on the 503 flooding topology (FT) from node A's point of view. 505 For a link between node A and node B, not on the current FT, after 506 node A computes a new FT and the link is on the new FT, it sends a 507 Hello with FT-bit set to one to node B. Similarly, after node B 508 computes a new FT and the link is on the new FT, it sends a Hello 509 with FT-bit set to one to node A. Note that Hello may include FT-bit 510 after the state of the adjacency between A and B is FULL. 512 For a link between node A and node B, on the current FT, after node A 513 computes a new FT and the link is not on the new FT, it sends a Hello 514 with FT-bit set to zero to node B. Similarly, after node B computes 515 a new FT and the link is not on the new FT, it sends a Hello with FT- 516 bit set to zero to node A. 518 If the Hellos from the two nodes have the same FT-bit value, then the 519 FT for the link between the two nodes is consistent; otherwise, it is 520 not consistent. 522 If one of the two nodes receives the Hellos with FT-bit set to one 523 from the other, but sends the Hellos with FT-bit set to zero for a 524 number of Hellos such as 5 Hellos or a given time, then the FT for 525 the link between the two nodes is not consistent. 527 When an inconsistency on the FT for a link is detected, a warning is 528 issued or logged, and the node receiving the Hellos with FT-bit set 529 to one from the other node assumes that the link is on the FT 530 temporarily and floods the link states over the link. 532 4.2.2. Extensions to IS-IS 534 A new TLV, called Extended Options and Flag (EOF) TLV, is defined. 535 It may be included in an IS-IS Hello. Its format is shown below. 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Type (TBD) | Length (4) | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Extended Options and Flags | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 EOF-TLV in IS-IS Hello 547 Similar to OSPF, a new flag bit (bit 31 suggested), called link on 548 flooding topology (FT-bit for short), is defined in EOF TLV. When a 549 node B receives a Hello from its adjacent node A over a link, FT-bit 550 set to one in the Hello indicates that the link is on the FT from 551 node A's point of view. 553 5. Flooding Behavior 555 This section describes the revised flooding behavior for a node. The 556 revised flooding procedure MUST flood an LS to every node in the 557 network in any case, as the standard flooding procedure does. 559 5.1. Nodes Perform Flooding Reduction without Failure 561 5.1.1. Receiving an LS 563 When a node receives a newer LS that is not originated by itself from 564 one of its interfaces, it floods the LS only to all the other 565 interfaces that are on the flooding topology. 567 When the LS is received from an interface on the flooding topology, 568 it is flooded only to all the other interfaces that are on the 569 flooding topology. When the LS is received on an interface that is 570 not on the flooding topology, it is also flooded only to all the 571 other interfaces that are on the flooding topology. 573 In any case, the LS must not be transmitted back to the receiving 574 interface. 576 Note before forwarding a received LS, the node would do the normal 577 processing as usual. 579 5.1.2. Originating an LS 581 When a node originates an LS, it floods the LS to its interfaces on 582 the flooding topology if the LS is a refresh LS (i.e., there is no 583 significant change in the LS comparing to the previous LS); otherwise 584 (i.e., there are significant changes such as link down in the LS), it 585 floods the LS to all its interfaces. Choosing flooding the LS with 586 significant changes to all the interfaces instead of limiting to the 587 interfaces on the flooding topology would speed up the distribution 588 of the significant link state changes. 590 5.1.3. Establishing Adjacencies 592 Adjacencies being established can be classified into two categories: 593 adjacencies to new nodes and adjacencies to existing nodes. 595 5.1.3.1. Adjacency to New Node 597 An adjacency to a new node is an adjacency between an existing node 598 (say node E) on the flooding topology and the new node (say node N) 599 which is not on the flooding topology. There is not any adjacency 600 between node N and a node in the network area. The procedure for 601 establishing the adjacency between E and N is the existing normal 602 procedure unchanged. 604 When the adjacency between N and E is established, node E adds node N 605 and the link between N and E to the flooding topology temporarily 606 until a new flooding topology is built. New node N adds node N and 607 the link between N and E to the flooding topology temporarily until a 608 new flooding topology is built. 610 5.1.3.2. Adjacency to Existing Node 612 An adjacency to an existing node is an adjacency between two nodes 613 (say nodes E and X) on the flooding topology. The procedure for 614 establishing the adjacency between E and X is the existing normal 615 procedure unchanged. 617 Both node E and node X assume that the link between E and X is not on 618 the flooding topology until a new flooding topology is built. After 619 the adjacency between E and X is established, node E does not send 620 node X any new or updated LS that it receives or originates, and node 621 X does not send node E any new or updated LS that it receives or 622 originates until a new flooding topology is built. 624 5.2. An Exception Case 626 5.2.1. Multiple Failures 628 When a node detects that two or more failures on the current flooding 629 topology occur before a new flooding topology is built, it enables 630 one flooding topology protection method in section 3.4. 632 5.2.2. Changes on Flooding Topology 634 After one or more failures split the current (old) flooding topology, 635 some link states may be out of synchronization among some nodes. 636 This can be resolved as follows. 638 After a node N computes a new flooding topology, for a local link L 639 attached to node N, if 1) link L is not on the current (old) flooding 640 topology and is on the new flooding topology, and 2) there is a 641 failure after the current (old) flooding topology is built, then node 642 N sends a delta of the link states that it received or originated to 643 its adjacent node over link L. 645 For node N, the delta of the link states is the link states with 646 changes that node N received or originated during the period of time 647 in which the current (old) flooding topology is split. 649 Suppose that Max_Split_Period is a number (in seconds), which is the 650 maximum period of time in which a flooding topology is split. Tc is 651 the time at which the current (old) flooding topology is built, Tn is 652 the time at which the new flooding topology is built, and Ts is the 653 bigger one between Tc and (Tn - Max_Split_Period). Node N sends its 654 adjacent node over link L the link states with changes that it 655 received or originated from Ts to Tn. 657 6. Operations on Flooding Reduction 659 6.1. Configuring Flooding Reduction 661 This section describes configurations for distributed flooding 662 reduction (i.e., flooding reduction in distributed mode). 664 6.1.1. Configurations for Distributed Flooding Reduction 666 For distributed flooding reduction, an algorithm for computing a 667 flooding topology needs to be configured. The algorithm and 668 distributed mode are configured on a node such as the area leader, 669 which tells the other nodes in the area the algorithm and the mode 670 via advertising the number of the algorithm and the mode. Every node 671 participating in the distributed flooding reduction uses this same 672 algorithm. 674 6.2. Migration to Flooding Reduction 676 Migrating a OSPF or IS-IS area from normal flooding to flooding 677 reduction smoothly takes a few steps or stages. This section 678 describes the steps for migrating an area to distributed flooding 679 reduction from normal flooding. 681 6.2.1. Migration to Distributed Flooding Reduction 683 At first, a user selects the distributed mode on a node such as the 684 area leader node, which tells the other nodes in the area to use 685 distributed flooding reduction. 687 After a node knows that the distributed mode is used, it advertises 688 the algorithms it supports. A user may check whether every node 689 advertises its supporting algorithms through showing the link state 690 containing the algorithms. 692 And then, a user selects an algorithm and activates the flooding 693 reduction through using configurations such as perform flooding 694 Reduction, which tells all the nodes in the area to use the given 695 algorithm and start the distributed flooding reduction. 697 6.3. Roll Back to Normal Flooding 699 For rolling back from flooding reduction to normal flooding, a user 700 de-activates the flooding reduction through configuring roll back to 701 normal flooding on a node, which tells all the nodes in the area to 702 roll back to normal flooding. 704 After receiving a configuration to roll back to normal flooding, the 705 node floods link states using all its local links instead of the 706 local links on the flooding topology. It also advertises the roll 707 back to Normal flooding to all the other nodes in the area. When 708 each of the other nodes receives the advertisement, it rolls back to 709 normal flooding (i.e., floods link states using all its local links 710 instead of the local links on the flooding topology). 712 In distributed mode, every node in the area will not compute or build 713 flooding topology. 715 7. Manageability Considerations 717 Section 6 "Operations on Flooding Reduction" outlines the 718 configuration process and deployment scenarios for link state 719 flooding reduction. The flooding reduction function may be 720 controlled by a policy module and assigned a suitable user privilege 721 level to enable. A suitable model may be required to verify the 722 flooding reduction status on routers participating in the flooding 723 reduction, including their role as a normal node advertising link 724 states using flooding topology. The mechanisms defined in this 725 document do not imply any new liveness detection and monitoring 726 requirements in addition to those indicated in [RFC2328] and 727 [RFC1195]. 729 8. Security Considerations 731 A notable beneficial security aspect of link state flooding reduction 732 is that a link state is not advertised over every link, but over the 733 links on the flooding topology. The malicious node could inject a 734 link state with a different algorithm, which could trigger the 735 flooding topology computation using the algorithm. Good security 736 practice might reuse the IS-IS authentication in [RFC5304] as well as 737 [RFC5310], and the OSPF authentication and other security mechanisms 738 described in [RFC2328], [RFC4552] and [RFC7474] to mitigate this type 739 of risk. 741 9. IANA Considerations 743 9.1. OSPF 745 Under Registry Name: OSPF Router Information (RI) TLVs [RFC7770], 746 IANA is requested to assign one new TLV value for OSPF distributed 747 flooding reduction as follows: 749 +===========+===========================+===============+ 750 | TLV Value | TLV Name | reference | 751 +===========+===========================+===============+ 752 | 11 | Scheduler Parameters TLV | This document | 753 +-----------+---------------------------+---------------+ 755 9.2. IS-IS 757 Under Registry Name: IS-IS TLV Codepoints, IANA is requested to 758 assign new TLV values for IS-IS distributed flooding reduction as 759 follows: 761 +===========+==============================+===============+ 762 | TLV Value | TLV Name | reference | 763 +===========+==============================+===============+ 764 | 151 |Scheduler Parameters TLV | This document | 765 +-----------+------------------------------+---------------+ 766 | 152 |Extended Options and Flag TLV | This document | 767 +-----------+------------------------------+---------------+ 769 10. Acknowledgements 771 The authors would like to thank Acee Lindem, Zhibo Hu, Robin Li, 772 Stephane Litkowski and Alvaro Retana for their valuable suggestions 773 and comments on this draft. 775 11. References 777 11.1. Normative References 779 [I-D.ietf-lsr-dynamic-flooding] 780 Li, T., Psenak, P., Ginsberg, L., Przygienda, T., Cooper, 781 D., Jalil, L., and S. Dontula, "Dynamic Flooding on Dense 782 Graphs", draft-ietf-lsr-dynamic-flooding-00 (work in 783 progress), February 2019. 785 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 786 dual environments", RFC 1195, DOI 10.17487/RFC1195, 787 December 1990, . 789 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 790 Requirement Levels", BCP 14, RFC 2119, 791 DOI 10.17487/RFC2119, March 1997, 792 . 794 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 795 DOI 10.17487/RFC2328, April 1998, 796 . 798 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 799 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 800 . 802 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 803 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 804 July 2008, . 806 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 807 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 808 2008, . 810 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 811 and M. Fanto, "IS-IS Generic Cryptographic 812 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 813 2009, . 815 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 816 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 817 . 819 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 820 "Security Extension for OSPFv2 When Using Manual Key 821 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 822 . 824 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 825 S. Shaffer, "Extensions to OSPF for Advertising Optional 826 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 827 February 2016, . 829 11.2. Informative References 831 [I-D.ietf-rtgwg-spf-uloop-pb-statement] 832 Litkowski, S., Decraene, B., and M. Horneffer, "Link State 833 protocols SPF trigger and delay algorithm impact on IGP 834 micro-loops", draft-ietf-rtgwg-spf-uloop-pb-statement-10 835 (work in progress), January 2019. 837 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 838 IANA Considerations Section in RFCs", RFC 5226, 839 DOI 10.17487/RFC5226, May 2008, 840 . 842 Appendix A. Algorithms to Build Flooding Topology 844 There are many algorithms to build a flooding topology. A simple and 845 efficient one is briefed below. 847 o Select a node R according to a rule such as the node with the 848 biggest/smallest node ID; 850 o Build a tree using R as root of the tree (details below); and then 852 o Connect k (k>=0) leaves to the tree to have a flooding topology 853 (details follow). 855 A.1. Algorithms to Build Tree without Considering Others 857 An algorithm for building a tree from node R as root starts with a 858 candidate queue Cq containing R and an empty flooding topology Ft: 860 1. Remove the first node A from Cq and add A into Ft 862 2. If Cq is empty, then return with Ft 864 3. Suppose that node Xi (i = 1, 2, ..., n) is connected to node A 865 and not in Ft and X1, X2, ..., Xn are in a special order. For 866 example, X1, X2, ..., Xn are ordered by the cost of the link 867 between A and Xi. The cost of the link between A and Xi is less 868 than the cost of the link between A and Xj (j = i + 1). If two 869 costs are the same, Xi's ID is less than Xj's ID. In another 870 example, X1, X2, ..., Xn are ordered by their IDs. If they are 871 not ordered, then make them in the order. 873 4. Add Xi (i = 1, 2, ..., n) into the end of Cq, goto step 1. 875 Another algorithm for building a tree from node R as root starts with 876 a candidate queue Cq containing R and an empty flooding topology Ft: 878 1. Remove the first node A from Cq and add A into Ft 880 2. If Cq is empty, then return with Ft 882 3. Suppose that node Xi (i = 1, 2, ..., n) is connected to node A 883 and not in Ft and X1, X2, ..., Xn are in a special order. For 884 example, X1, X2, ..., Xn are ordered by the cost of the link 885 between A and Xi. The cost of the link between A and Xi is less 886 than the cost of the link between A and Xj (j = i + 1). If two 887 costs are the same, Xi's ID is less than Xj's ID. In another 888 example, X1, X2, ..., Xn are ordered by their IDs. If they are 889 not ordered, then make them in the order. 891 4. Add Xi (i = 1, 2, ..., n) into the front of Cq and goto step 1. 893 A third algorithm for building a tree from node R as root starts with 894 a candidate list Cq containing R associated with cost 0 and an empty 895 flooding topology Ft: 897 1. Remove the first node A from Cq and add A into Ft 899 2. If all the nodes are on Ft, then return with Ft 901 3. Suppose that node A is associated with a cost Ca which is the 902 cost from root R to node A, node Xi (i = 1, 2, ..., n) is 903 connected to node A and not in Ft and the cost of the link 904 between A and Xi is LCi (i=1, 2, ..., n). Compute Ci = Ca + LCi, 905 check if Xi is in Cq and if Cxi (cost from R to Xi) < Ci. If Xi 906 is not in Cq, then add Xi with cost Ci into Cq; If Xi is in Cq, 907 then If Cxi > Ci then replace Xi with cost Cxi by Xi with Ci in 908 Cq; If Cxi == Ci then add Xi with cost Ci into Cq. 910 4. Make sure Cq is in a special order. Suppose that Ai (i=1, 2, 911 ..., m) are the nodes in Cq, Cai is the cost associated with Ai, 912 and IDi is the ID of Ai. One order is that for any k = 1, 2, 913 ..., m-1, Cak < Caj (j = k+1) or Cak = Caj and IDk < IDj. Goto 914 step 1. 916 A.2. Algorithms to Build Tree Considering Others 918 An algorithm for building a tree from node R as root with 919 consideration of others's support for flooding reduction starts with 920 a candidate queue Cq containing R associated with previous hop PH=0 921 and an empty flooding topology Ft: 923 1. Remove the first node A that supports flooding reduction from the 924 candidate queue Cq if there is such a node A; otherwise (i.e., if 925 there is not such node A in Cq), then remove the first node A 926 from Cq. Add A into the flooding topology Ft. 928 2. If Cq is empty or all nodes are on Ft, then return with Ft 930 3. Suppose that node Xi (i = 1, 2, ..., n) is connected to node A 931 and not in the flooding topology Ft and X1, X2, ..., Xn are in a 932 special order considering whether some of them that support 933 flooding reduction (. For example, X1, X2, ..., Xn are ordered 934 by the cost of the link between A and Xi. The cost of the link 935 between A and Xi is less than that of the link between A and Xj 936 (j = i + 1). If two costs are the same, Xi's ID is less than 937 Xj's ID. The cost of a link is redefined such that 1) the cost 938 of a link between A and Xi both support flooding reduction is 939 much less than the cost of any link between A and Xk where Xk 940 with F=0; 2) the real metric of a link between A and Xi and the 941 real metric of a link between A and Xk are used as their costs 942 for determining the order of Xi and Xk if they all (i.e., A, Xi 943 and Xk) support flooding reduction or none of Xi and Xk support 944 flooding reduction. 946 4. Add Xi (i = 1, 2, ..., n) associated with previous hop PH=A into 947 the end of the candidate queue Cq, and goto step 1. 949 Another algorithm for building a tree from node R as root with 950 consideration of others' support for flooding reduction starts with a 951 candidate queue Cq containing R associated with previous hop PH=0 and 952 an empty flooding topology Ft: 954 1. Remove the first node A that supports flooding reduction from the 955 candidate queue Cq if there is such a node A; otherwise (i.e., if 956 there is not such node A in Cq), then remove the first node A 957 from Cq. Add A into the flooding topology Ft. 959 2. If Cq is empty or all nodes are on Ft, then return with Ft. 961 3. Suppose that node Xi (i = 1, 2, ..., n) is connected to node A 962 and not in the flooding topology Ft and X1, X2, ..., Xn are in a 963 special order considering whether some of them support flooding 964 reduction. For example, X1, X2, ..., Xn are ordered by the cost 965 of the link between A and Xi. The cost of the link between A and 966 Xi is less than the cost of the link between A and Xj (j = i + 967 1). If two costs are the same, Xi's ID is less than Xj's ID. 968 The cost of a link is redefined such that 1) the cost of a link 969 between A and Xi both support flooding reduction is much less 970 than the cost of any link between A and Xk where Xk does not 971 support flooding reduction; 2) the real metric of a link between 972 A and Xi and the real metric of a link between A and Xk are used 973 as their costs for determining the order of Xi and Xk if they all 974 (i.e., A, Xi and Xk) support flooding reduction or none of Xi and 975 Xk supports flooding reduction. 977 4. Add Xi (i = 1, 2, ..., n) associated with previous hop PH=A into 978 the front of the candidate queue Cq, and goto step 1. 980 A third algorithm for building a tree from node R as root with 981 consideration of others' support for flooding reduction (using flag F 982 = 1 for support, and F = 0 for not support in the following) starts 983 with a candidate list Cq containing R associated with low order cost 984 Lc=0, high order cost Hc=0 and previous hop ID PH=0, and an empty 985 flooding topology Ft: 987 1. Remove the first node A from Cq and add A into Ft. 989 2. If all the nodes are on Ft, then return with Ft 991 3. Suppose that node A is associated with a cost Ca which is the 992 cost from root R to node A, node Xi (i = 1, 2, ..., n) is 993 connected to node A and not in Ft and the cost of the link 994 between A and Xi is LCi (i=1, 2, ..., n). Compute Ci = Ca + LCi, 995 check if Xi is in Cq and if Cxi (cost from R to Xi) < Ci. If Xi 996 is not in Cq, then add Xi with cost Ci into Cq; If Xi is in Cq, 997 then If Cxi > Ci then replace Xi with cost Cxi by Xi with Ci in 998 Cq; If Cxi == Ci then add Xi with cost Ci into Cq. 1000 4. Suppose that node A is associated with a low order cost LCa which 1001 is the low order cost from root R to node A and a high order cost 1002 HCa which is the high order cost from R to A, node Xi (i = 1, 2, 1003 ..., n) is connected to node A and not in the flooding topology 1004 Ft and the real cost of the link between A and Xi is Ci (i=1, 2, 1005 ..., n). Compute LCxi and HCxi: LCxi = LCa + Ci if both A and Xi 1006 have flag F set to one, otherwise LCxi = LCa HCxi = HCa + Ci if A 1007 or Xi does not have flag F set to one, otherwise HCxi = HCa If Xi 1008 is not in Cq, then add Xi associated with LCxi, HCxi and PH = A 1009 into Cq; If Xi associated with LCxi' and HCxi' and PHxi' is in 1010 Cq, then If HCxi' > HCxi then replace Xi with HCxi', LCxi' and 1011 PHxi' by Xi with HCxi, LCxi and PH=A in Cq; otherwise (i.e., 1012 HCxi' == HCxi) if LCxi' > LCxi , then replace Xi with HCxi', 1013 LCxi' and PHxi' by Xi with HCxi, LCxi and PH=A in Cq; otherwise 1014 (i.e., HCxi' == HCxi and LCxi' == LCxi) if PHxi' > PH, then 1015 replace Xi with HCxi', LCxi' and PHxi' by Xi with HCxi, LCxi and 1016 PH=A in Cq. 1018 5. Make sure Cq is in a special order. Suppose that Ai (i=1, 2, 1019 ..., m) are the nodes in Cq, HCai and LCai are low order cost and 1020 high order cost associated with Ai, and IDi is the ID of Ai. One 1021 order is that for any k = 1, 2, ..., m-1, HCak < HCaj (j = k+1) 1022 or HCak = HCaj and LCak < LCaj or HCak = HCaj and LCak = LCaj and 1023 IDk < IDj. Goto step 1. 1025 A.3. Connecting Leaves 1027 Suppose that we have a flooding topology Ft built by one of the 1028 algorithms described above. Ft is like a tree. We may connect k (k 1029 >=0) leaves to the tree to have a enhanced flooding topology with 1030 more connectivity. 1032 Suppose that there are m (0 < m) leaves directly connected to a node 1033 X on the flooding topology Ft. Select k (k <= m) leaves through 1034 using a deterministic algorithm or rule. One algorithm or rule is to 1035 select k leaves that have smaller or larger IDs (i.e., the IDs of 1036 these k leaves are smaller/bigger than the IDs of the other leaves 1037 directly connected to node X). Since every node has a unique ID, 1038 selecting k leaves with smaller or larger IDs is deterministic. 1040 If k = 1, the leaf selected has the smallest/largest node ID among 1041 the IDs of all the leaves directly connected to node X. 1043 For a selected leaf L directly connected to a node N in the flooding 1044 topology Ft, select a connection/adjacency to another node from node 1045 L in Ft through using a deterministic algorithm or rule. 1047 Suppose that leaf node L is directly connected to nodes Ni (i = 1048 1,2,...,s) in the flooding topology Ft via adjacencies and node Ni is 1049 not node N, IDi is the ID of node Ni, and Hi (i = 1,2,...,s) is the 1050 number of hops from node L to node Ni in the flooding topology Ft. 1052 One Algorithm or rule is to select the connection to node Nj (1 <= j 1053 <= s) such that Hj is the largest among H1, H2, ..., Hs. If there is 1054 another node Na ( 1 <= a <= s) and Hj = Ha, then select the one with 1055 smaller (or larger) node ID. That is that if Hj == Ha and IDj < IDa 1056 then select the connection to Nj for selecting the one with smaller 1057 node ID (or if Hj == Ha and IDj < IDa then select the connection to 1058 Na for selecting the one with larger node ID). 1060 Suppose that the number of connections in total between leaves 1061 selected and the nodes in the flooding topology Ft to be added is 1062 NLc. We may have a limit to NLc. 1064 Authors' Addresses 1066 Huaimo Chen 1067 Huawei Technologies 1068 Boston 1069 USA 1071 Email: huaimo.chen@huawei.com 1073 Dean Cheng 1074 Huawei Technologies 1075 Santa Clara 1076 USA 1078 Email: dean.cheng@huawei.com 1079 Mehmet Toy 1080 Verizon 1081 USA 1083 Email: mehmet.toy@verizon.com 1085 Yi Yang 1086 IBM 1087 Cary, NC 1088 United States of America 1090 Email: yyietf@gmail.com 1092 Aijun Wang 1093 China Telecom 1094 Beiqijia Town, Changping District 1095 Beijing 102209 1096 China 1098 Email: wangaj.bri@chinatelecom.cn 1100 Xufeng Liu 1101 Volta Networks 1102 McLean, VA 1103 USA 1105 Email: xufeng.liu.ietf@gmail.com 1107 Yanhe Fan 1108 Casa Systems 1109 USA 1111 Email: yfan@casa-systems.com 1113 Lei Liu 1114 USA 1116 Email: liulei.kddi@gmail.com