idnits 2.17.1 draft-cc-lsr-flooding-reduction-02.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 10, 2019) is 1867 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 794, but no explicit reference was found in the text == Unused Reference: 'RFC5340' is defined on line 807, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 829, 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 11, 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 10, 2019 18 LS Distributed Flooding Reduction 19 draft-cc-lsr-flooding-reduction-02 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 11, 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 . . . . 12 90 5.1.1. Receiving an LS . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . 14 98 6.1. Configuring Flooding Reduction . . . . . . . . . . . . . 14 99 6.1.1. Configurations for Distributed Flooding Reduction . . 14 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . 18 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, node N adds 327 the links (e.g., L1 and L2) to the flooding topology temporarily 328 until a new flooding topology is built. 330 Suppose that the two end nodes of link L is A and B, and A's ID is 331 smaller than B's. Node N computes a path from A to B with minimum 332 hops and whose links are not on the flooding topology. This path is 333 a backup path for link L. 335 Similarly, for a backup path for a connection crossing a node M on 336 the flooding topology, a node N computes and maintains it only if the 337 backup path goes through node N. Node N stores the links (e.g., 338 local link La and Lb) attached to it and on the backup path for node 339 M. 341 4. Protocol Extensions 343 The extensions comprises two parts: one part is for operations on 344 flooding reduction, the other is for flooding topology consistency. 346 4.1. Extensions for Operations 348 4.1.1. Extensions to OSPF 350 The OSPF Dynamic Flooding sub-TLV and area leader sub-TLV are defined 351 in [I-D.ietf-lsr-dynamic-flooding]. The former may contains a number 352 of algorithms. The latter contains instructions about flooding 353 reduction. 355 Every node supporting the distributed flooding reduction MUST 356 indicate its algorithms for flooding topology computation in a OSPF 357 Dynamic Flooding sub-TLV. This sub-TLV in a RI LSA will be 358 advertised to the area leader. 360 When the distributed flooding reduction is selected, every node MUST 361 receive the OSPF area leader sub-TLV in a RI LSA from the area 362 leader, which indicates the distributed mode and an algorithm to be 363 used. It SHOULD receive the parameters needed for the algorithm and 364 the distributed mode. 366 The parameters for the distributed mode include those three 367 parameters configured for the scheduler for flooding topology 368 computation. Through configuring these parameters on one place such 369 as the area leader and automatically advertising them to every node 370 in the network, we simplify the operation on flooding reduction and 371 reduce the errors on configurations (comparing to manually 372 configuring these parameters on every node). 374 A new sub-TLV, called OSPF Scheduler Parameters sub-TLV, is defined 375 for advertising the three parameters configured for the scheduler. 376 Its format is illustrated below. 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Type (TBD1) | Length (8) | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | initial-delay | minimum-hold-time | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | maximum-wait-time | Reserved (MUST be zero) | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 OSPF Scheduler Parameters sub-TLV 390 Type: TBD1 for Scheduler Parameters is to be assigned by IANA. 392 Length: 8. 394 initial-delay: 2 octets' field representing the initial delay in 395 milliseconds. 397 minimum-hold-time: 2 octets' field representing the minimum hold 398 time in milliseconds. 400 maximum-wait-time: 2 octets' field representing the maximum wait 401 time in milliseconds. 403 Reserved: MUST be set to 0 while sending and ignored on receipt. 405 In the case where the distributed flooding reduction is selected and 406 an algorithm for flooding topology computation is given already, 407 there are some operational changes. These changes include: 409 1 the algorithm given is changed to another algorithm; 411 2 the distributed flooding reduction is rolled back to normal 412 flooding; and 414 3 the distributed flooding reduction is changed to centralized 415 flooding reduction. 417 For the first change, every node MUST receive the OSPF area leader 418 sub-TLV in a RI LSA from the leader, which indicates that another 419 algorithm is to be used. After receiving the sub-TLV, it uses the 420 new algorithm to compute a new flooding topology, and floods link 421 states over both the flooding topology computed by the old algorithm 422 and the new flooding topology for a given time. And then it will 423 floods link states over the flooding topology computed by the new 424 algorithm. 426 For the second change, every node MUST receive the OSPF area leader 427 sub-TLV in a RI LSA from the leader, which indicates the current 428 flooding reduction is to be rolled back to normal flooding. After 429 receiving the sub-TLV, it stops computing flooding topology and 430 flooding link states over a flooding topology. It floods link states 431 using all its local links instead of the local links on the flooding 432 topology. 434 Note that the OSPF area leader sub-TLV defined in 435 [I-D.ietf-lsr-dynamic-flooding] needs to be extended to allow users 436 to roll back to normal flooding. The Flooding Reduction Instruction 437 sub-TLV defined in the previous version of this draft supports this. 439 4.1.2. Extensions to IS-IS 441 Similar to OSPF, the IS-IS Dynamic Flooding sub-TLV and area leader 442 sub-TLV are also defined in [I-D.ietf-lsr-dynamic-flooding]. 444 Every node supporting the distributed flooding reduction MUST 445 indicate its algorithms for flooding topology computation in an IS-IS 446 Dynamic Flooding sub-TLV in an LSP to be advertised to the leader. 448 When the distributed flooding reduction is selected, every node MUST 449 receive the IS-IS area leader sub-TLV in an LSP, which indicates the 450 distributed mode and an algorithm to be used. It SHOULD receive the 451 parameters needed for the algorithm and the distributed mode. 453 A new sub-TLV, called IS-IS Scheduler Parameters sub-TLV, is defined 454 for advertising the three parameters configured for the scheduler. 455 Its format is illustrated below. 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Type (TBD2) | Length (8) | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | initial-delay | minimum-hold-time | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | maximum-wait-time | Reserved (MUST be zero) | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 IS-IS Scheduler Parameters sub-TLV 469 Type: TBD1 for Scheduler Parameters is to be assigned by IANA. 471 Length: 8. 473 initial-delay: 2 octets' field representing the initial delay in 474 milliseconds. 476 minimum-hold-time: 2 octets' field representing the minimum hold 477 time in milliseconds. 479 maximum-wait-time: 2 octets' field representing the maximum wait 480 time in milliseconds. 482 Reserved: MUST be set to 0 while sending and ignored on receipt. 484 4.2. Extensions for Consistency 486 4.2.1. Extensions to OSPF 488 RFC 5613 defines a TLV called Extended Options and Flag (EOF) TLV. A 489 OSPF Hello may contain this TLV in link-local signaling (LLS) data 490 block. A new flag bit (bit 30 suggested), called link on flooding 491 topology (FT-bit for short), is defined in EOF TLV. 493 When a node B receives a Hello from its adjacent node A over a link, 494 FT-bit set to one in the Hello indicates that the link is on the 495 flooding topology (FT) from node A's point of view. 497 For a link between node A and node B, not on the current FT, after 498 node A computes a new FT and the link is on the new FT, it sends a 499 Hello with FT-bit set to one to node B. Similarly, after node B 500 computes a new FT and the link is on the new FT, it sends a Hello 501 with FT-bit set to one to node A. Note that Hello may include FT-bit 502 after the state of the adjacency between A and B is FULL. 504 For a link between node A and node B, on the current FT, after node A 505 computes a new FT and the link is not on the new FT, it sends a Hello 506 with FT-bit set to zero to node B. Similarly, after node B computes 507 a new FT and the link is not on the new FT, it sends a Hello with FT- 508 bit set to zero to node A. 510 If the Hellos from the two nodes have the same FT-bit value, then the 511 FT for the link between the two nodes is consistent; otherwise, it is 512 not consistent. 514 If one of the two nodes receives the Hellos with FT-bit set to one 515 from the other, but sends the Hellos with FT-bit set to zero for a 516 number of Hellos such as 5 Hellos or a given time, then the FT for 517 the link between the two nodes is not consistent. 519 When an inconsistency on the FT for a link is detected, a warning is 520 issued or logged, and the node receiving the Hellos with FT-bit set 521 to one from the other node assumes that the link is on the FT 522 temporarily and floods the link states over the link. 524 4.2.2. Extensions to IS-IS 526 A new TLV, called Extended Options and Flag (EOF) TLV, is defined. 527 It may be included in an IS-IS Hello. Its format is shown below. 529 0 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Type (TBD) | Length (4) | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Extended Options and Flags | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 EOF-TLV in IS-IS Hello 539 Similar to OSPF, a new flag bit (bit 31 suggested), called link on 540 flooding topology (FT-bit for short), is defined in EOF TLV. When a 541 node B receives a Hello from its adjacent node A over a link, FT-bit 542 set to one in the Hello indicates that the link is on the FT from 543 node A's point of view. 545 5. Flooding Behavior 547 This section describes the revised flooding behavior for a node. The 548 revised flooding procedure MUST flood an LS to every node in the 549 network in any case, as the standard flooding procedure does. 551 5.1. Nodes Perform Flooding Reduction without Failure 553 5.1.1. Receiving an LS 555 When a node receives a newer LS that is not originated by itself from 556 one of its interfaces, it floods the LS only to all the other 557 interfaces that are on the flooding topology. 559 When the LS is received from an interface on the flooding topology, 560 it is flooded only to all the other interfaces that are on the 561 flooding topology. When the LS is received on an interface that is 562 not on the flooding topology, it is also flooded only to all the 563 other interfaces that are on the flooding topology. 565 In any case, the LS must not be transmitted back to the receiving 566 interface. 568 Note before forwarding a received LS, the node would do the normal 569 processing as usual. 571 5.1.2. Originating an LS 573 When a node originates an LS, it floods the LS to its interfaces on 574 the flooding topology if the LS is a refresh LS (i.e., there is no 575 significant change in the LS comparing to the previous LS); otherwise 576 (i.e., there are significant changes such as link down in the LS), it 577 floods the LS to all its interfaces. Choosing flooding the LS with 578 significant changes to all the interfaces instead of limiting to the 579 interfaces on the flooding topology would speed up the distribution 580 of the significant link state changes. 582 5.1.3. Establishing Adjacencies 584 Adjacencies being established can be classified into two categories: 585 adjacencies to new nodes and adjacencies to existing nodes. 587 5.1.3.1. Adjacency to New Node 589 An adjacency to a new node is an adjacency between an existing node 590 (say node E) on the flooding topology and the new node (say node N) 591 which is not on the flooding topology. There is not any adjacency 592 between node N and a node in the network area. The procedure for 593 establishing the adjacency between E and N is the existing normal 594 procedure unchanged. 596 When the adjacency between N and E is established, node E adds node N 597 and the link between N and E to the flooding topology temporarily 598 until a new flooding topology is built. New node N adds node N and 599 the link between N and E to the flooding topology temporarily until a 600 new flooding topology is built. 602 5.1.3.2. Adjacency to Existing Node 604 An adjacency to an existing node is an adjacency between two nodes 605 (say nodes E and X) on the flooding topology. The procedure for 606 establishing the adjacency between E and X is the existing normal 607 procedure unchanged. 609 Both node E and node X assume that the link between E and X is not on 610 the flooding topology until a new flooding topology is built. After 611 the adjacency between E and X is established, node E does not send 612 node X any new or updated LS that it receives or originates, and node 613 X does not send node E any new or updated LS that it receives or 614 originates until a new flooding topology is built. 616 5.2. An Exception Case 618 5.2.1. Multiple Failures 620 When a node detects that two or more failures on the current flooding 621 topology occur before a new flooding topology is built, it enables 622 one flooding topology protection method in section 3.4. 624 5.2.2. Changes on Flooding Topology 626 After one or more failures split the current (old) flooding topology, 627 some link states may be out of synchronization among some nodes. 628 This can be resolved as follows. 630 After a node N computes a new flooding topology, for a local link L 631 attached to node N, if 1) link L is not on the current (old) flooding 632 topology and is on the new flooding topology, and 2) there is a 633 failure after the current (old) flooding topology is built, then node 634 N sends a delta of the link states that it received or originated to 635 its adjacent node over link L. 637 For node N, the delta of the link states is the link states with 638 changes that node N received or originated during the period of time 639 in which the current (old) flooding topology is split. 641 Suppose that Max_Split_Period is a number (in seconds), which is the 642 maximum period of time in which a flooding topology is split. Tc is 643 the time at which the current (old) flooding topology is built, Tn is 644 the time at which the new flooding topology is built, and Ts is the 645 bigger one between Tc and (Tn - Max_Split_Period). Node N sends its 646 adjacent node over link L the link states with changes that it 647 received or originated from Ts to Tn. 649 6. Operations on Flooding Reduction 651 6.1. Configuring Flooding Reduction 653 This section describes configurations for distributed flooding 654 reduction (i.e., flooding reduction in distributed mode). 656 6.1.1. Configurations for Distributed Flooding Reduction 658 For distributed flooding reduction, an algorithm for computing a 659 flooding topology needs to be configured. The algorithm and 660 distributed mode are configured on a node such as the area leader, 661 which tells the other nodes in the area the algorithm and the mode 662 via advertising the number of the algorithm and the mode. Every node 663 participating in the distributed flooding reduction uses this same 664 algorithm. 666 6.2. Migration to Flooding Reduction 668 Migrating a OSPF or IS-IS area from normal flooding to flooding 669 reduction smoothly takes a few steps or stages. This section 670 describes the steps for migrating an area to distributed flooding 671 reduction from normal flooding. 673 6.2.1. Migration to Distributed Flooding Reduction 675 At first, a user selects the distributed mode on a node such as the 676 area leader node, which tells the other nodes in the area to use 677 distributed flooding reduction. 679 After a node knows that the distributed mode is used, it advertises 680 the algorithms it supports. A user may check whether every node 681 advertises its supporting algorithms through showing the link state 682 containing the algorithms. 684 And then, a user selects an algorithm and activates the flooding 685 reduction through using configurations such as perform flooding 686 Reduction, which tells all the nodes in the area to use the given 687 algorithm and start the distributed flooding reduction. 689 6.3. Roll Back to Normal Flooding 691 For rolling back from flooding reduction to normal flooding, a user 692 de-activates the flooding reduction through configuring roll back to 693 normal flooding on a node, which tells all the nodes in the area to 694 roll back to normal flooding. 696 After receiving a configuration to roll back to normal flooding, the 697 node floods link states using all its local links instead of the 698 local links on the flooding topology. It also advertises the roll 699 back to Normal flooding to all the other nodes in the area. When 700 each of the other nodes receives the advertisement, it rolls back to 701 normal flooding (i.e., floods link states using all its local links 702 instead of the local links on the flooding topology). 704 In distributed mode, every node in the area will not compute or build 705 flooding topology. 707 7. Manageability Considerations 709 Section 6 "Operations on Flooding Reduction" outlines the 710 configuration process and deployment scenarios for link state 711 flooding reduction. The flooding reduction function may be 712 controlled by a policy module and assigned a suitable user privilege 713 level to enable. A suitable model may be required to verify the 714 flooding reduction status on routers participating in the flooding 715 reduction, including their role as a normal node advertising link 716 states using flooding topology. The mechanisms defined in this 717 document do not imply any new liveness detection and monitoring 718 requirements in addition to those indicated in [RFC2328] and 719 [RFC1195]. 721 8. Security Considerations 723 A notable beneficial security aspect of link state flooding reduction 724 is that a link state is not advertised over every link, but over the 725 links on the flooding topology. The malicious node could inject a 726 link state with a different algorithm, which could trigger the 727 flooding topology computation using the algorithm. Good security 728 practice might reuse the IS-IS authentication in [RFC5304] as well as 729 [RFC5310], and the OSPF authentication and other security mechanisms 730 described in [RFC2328], [RFC4552] and [RFC7474] to mitigate this type 731 of risk. 733 9. IANA Considerations 735 9.1. OSPF 737 Under Registry Name: OSPF Router Information (RI) TLVs [RFC7770], 738 IANA is requested to assign one new TLV value for OSPF distributed 739 flooding reduction as follows: 741 +===========+===========================+===============+ 742 | TLV Value | TLV Name | reference | 743 +===========+===========================+===============+ 744 | 11 | Scheduler Parameters TLV | This document | 745 +-----------+---------------------------+---------------+ 747 9.2. IS-IS 749 Under Registry Name: IS-IS TLV Codepoints, IANA is requested to 750 assign new TLV values for IS-IS distributed flooding reduction as 751 follows: 753 +===========+==============================+===============+ 754 | TLV Value | TLV Name | reference | 755 +===========+==============================+===============+ 756 | 151 |Scheduler Parameters TLV | This document | 757 +-----------+------------------------------+---------------+ 758 | 152 |Extended Options and Flag TLV | This document | 759 +-----------+------------------------------+---------------+ 761 10. Acknowledgements 763 The authors would like to thank Acee Lindem, Zhibo Hu, Robin Li, 764 Stephane Litkowski and Alvaro Retana for their valuable suggestions 765 and comments on this draft. 767 11. References 769 11.1. Normative References 771 [I-D.ietf-lsr-dynamic-flooding] 772 Li, T., Psenak, P., Ginsberg, L., Przygienda, T., Cooper, 773 D., Jalil, L., and S. Dontula, "Dynamic Flooding on Dense 774 Graphs", draft-ietf-lsr-dynamic-flooding-00 (work in 775 progress), February 2019. 777 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 778 dual environments", RFC 1195, DOI 10.17487/RFC1195, 779 December 1990, . 781 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 782 Requirement Levels", BCP 14, RFC 2119, 783 DOI 10.17487/RFC2119, March 1997, 784 . 786 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 787 DOI 10.17487/RFC2328, April 1998, 788 . 790 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 791 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 792 . 794 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 795 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 796 July 2008, . 798 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 799 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 800 2008, . 802 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 803 and M. Fanto, "IS-IS Generic Cryptographic 804 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 805 2009, . 807 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 808 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 809 . 811 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., 812 "Security Extension for OSPFv2 When Using Manual Key 813 Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, 814 . 816 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 817 S. Shaffer, "Extensions to OSPF for Advertising Optional 818 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 819 February 2016, . 821 11.2. Informative References 823 [I-D.ietf-rtgwg-spf-uloop-pb-statement] 824 Litkowski, S., Decraene, B., and M. Horneffer, "Link State 825 protocols SPF trigger and delay algorithm impact on IGP 826 micro-loops", draft-ietf-rtgwg-spf-uloop-pb-statement-10 827 (work in progress), January 2019. 829 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 830 IANA Considerations Section in RFCs", RFC 5226, 831 DOI 10.17487/RFC5226, May 2008, 832 . 834 Appendix A. Algorithms to Build Flooding Topology 836 There are many algorithms to build a flooding topology. A simple and 837 efficient one is briefed below. 839 o Select a node R according to a rule such as the node with the 840 biggest/smallest node ID; 842 o Build a tree using R as root of the tree (details below); and then 844 o Connect k (k>=0) leaves to the tree to have a flooding topology 845 (details follow). 847 A.1. Algorithms to Build Tree without Considering Others 849 An algorithm for building a tree from node R as root starts with a 850 candidate queue Cq containing R and an empty flooding topology Ft: 852 1. Remove the first node A from Cq and add A into Ft 854 2. If Cq is empty, then return with Ft 856 3. Suppose that node Xi (i = 1, 2, ..., n) is connected to node A 857 and not in Ft and X1, X2, ..., Xn are in a special order. For 858 example, X1, X2, ..., Xn are ordered by the cost of the link 859 between A and Xi. The cost of the link between A and Xi is less 860 than the cost of the link between A and Xj (j = i + 1). If two 861 costs are the same, Xi's ID is less than Xj's ID. In another 862 example, X1, X2, ..., Xn are ordered by their IDs. If they are 863 not ordered, then make them in the order. 865 4. Add Xi (i = 1, 2, ..., n) into the end of Cq, goto step 1. 867 Another algorithm for building a tree from node R as root starts with 868 a candidate queue Cq containing R and an empty flooding topology Ft: 870 1. Remove the first node A from Cq and add A into Ft 872 2. If Cq is empty, then return with Ft 874 3. Suppose that node Xi (i = 1, 2, ..., n) is connected to node A 875 and not in Ft and X1, X2, ..., Xn are in a special order. For 876 example, X1, X2, ..., Xn are ordered by the cost of the link 877 between A and Xi. The cost of the link between A and Xi is less 878 than the cost of the link between A and Xj (j = i + 1). If two 879 costs are the same, Xi's ID is less than Xj's ID. In another 880 example, X1, X2, ..., Xn are ordered by their IDs. If they are 881 not ordered, then make them in the order. 883 4. Add Xi (i = 1, 2, ..., n) into the front of Cq and goto step 1. 885 A third algorithm for building a tree from node R as root starts with 886 a candidate list Cq containing R associated with cost 0 and an empty 887 flooding topology Ft: 889 1. Remove the first node A from Cq and add A into Ft 891 2. If all the nodes are on Ft, then return with Ft 893 3. Suppose that node A is associated with a cost Ca which is the 894 cost from root R to node A, node Xi (i = 1, 2, ..., n) is 895 connected to node A and not in Ft and the cost of the link 896 between A and Xi is LCi (i=1, 2, ..., n). Compute Ci = Ca + LCi, 897 check if Xi is in Cq and if Cxi (cost from R to Xi) < Ci. If Xi 898 is not in Cq, then add Xi with cost Ci into Cq; If Xi is in Cq, 899 then If Cxi > Ci then replace Xi with cost Cxi by Xi with Ci in 900 Cq; If Cxi == Ci then add Xi with cost Ci into Cq. 902 4. Make sure Cq is in a special order. Suppose that Ai (i=1, 2, 903 ..., m) are the nodes in Cq, Cai is the cost associated with Ai, 904 and IDi is the ID of Ai. One order is that for any k = 1, 2, 905 ..., m-1, Cak < Caj (j = k+1) or Cak = Caj and IDk < IDj. Goto 906 step 1. 908 A.2. Algorithms to Build Tree Considering Others 910 An algorithm for building a tree from node R as root with 911 consideration of others's support for flooding reduction starts with 912 a candidate queue Cq containing R associated with previous hop PH=0 913 and an empty flooding topology Ft: 915 1. Remove the first node A that supports flooding reduction from the 916 candidate queue Cq if there is such a node A; otherwise (i.e., if 917 there is not such node A in Cq), then remove the first node A 918 from Cq. Add A into the flooding topology Ft. 920 2. If Cq is empty or all nodes are on Ft, then return with Ft 922 3. Suppose that node Xi (i = 1, 2, ..., n) is connected to node A 923 and not in the flooding topology Ft and X1, X2, ..., Xn are in a 924 special order considering whether some of them that support 925 flooding reduction (. For example, X1, X2, ..., Xn are ordered 926 by the cost of the link between A and Xi. The cost of the link 927 between A and Xi is less than that of the link between A and Xj 928 (j = i + 1). If two costs are the same, Xi's ID is less than 929 Xj's ID. The cost of a link is redefined such that 1) the cost 930 of a link between A and Xi both support flooding reduction is 931 much less than the cost of any link between A and Xk where Xk 932 with F=0; 2) the real metric of a link between A and Xi and the 933 real metric of a link between A and Xk are used as their costs 934 for determining the order of Xi and Xk if they all (i.e., A, Xi 935 and Xk) support flooding reduction or none of Xi and Xk support 936 flooding reduction. 938 4. Add Xi (i = 1, 2, ..., n) associated with previous hop PH=A into 939 the end of the candidate queue Cq, and goto step 1. 941 Another algorithm for building a tree from node R as root with 942 consideration of others' support for flooding reduction starts with a 943 candidate queue Cq containing R associated with previous hop PH=0 and 944 an empty flooding topology Ft: 946 1. Remove the first node A that supports flooding reduction from the 947 candidate queue Cq if there is such a node A; otherwise (i.e., if 948 there is not such node A in Cq), then remove the first node A 949 from Cq. Add A into the flooding topology Ft. 951 2. If Cq is empty or all nodes are on Ft, then return with Ft. 953 3. Suppose that node Xi (i = 1, 2, ..., n) is connected to node A 954 and not in the flooding topology Ft and X1, X2, ..., Xn are in a 955 special order considering whether some of them support flooding 956 reduction. For example, X1, X2, ..., Xn are ordered by the cost 957 of the link between A and Xi. The cost of the link between A and 958 Xi is less than the cost of the link between A and Xj (j = i + 959 1). If two costs are the same, Xi's ID is less than Xj's ID. 960 The cost of a link is redefined such that 1) the cost of a link 961 between A and Xi both support flooding reduction is much less 962 than the cost of any link between A and Xk where Xk does not 963 support flooding reduction; 2) the real metric of a link between 964 A and Xi and the real metric of a link between A and Xk are used 965 as their costs for determining the order of Xi and Xk if they all 966 (i.e., A, Xi and Xk) support flooding reduction or none of Xi and 967 Xk supports flooding reduction. 969 4. Add Xi (i = 1, 2, ..., n) associated with previous hop PH=A into 970 the front of the candidate queue Cq, and goto step 1. 972 A third algorithm for building a tree from node R as root with 973 consideration of others' support for flooding reduction (using flag F 974 = 1 for support, and F = 0 for not support in the following) starts 975 with a candidate list Cq containing R associated with low order cost 976 Lc=0, high order cost Hc=0 and previous hop ID PH=0, and an empty 977 flooding topology Ft: 979 1. Remove the first node A from Cq and add A into Ft. 981 2. If all the nodes are on Ft, then return with Ft 983 3. Suppose that node A is associated with a cost Ca which is the 984 cost from root R to node A, node Xi (i = 1, 2, ..., n) is 985 connected to node A and not in Ft and the cost of the link 986 between A and Xi is LCi (i=1, 2, ..., n). Compute Ci = Ca + LCi, 987 check if Xi is in Cq and if Cxi (cost from R to Xi) < Ci. If Xi 988 is not in Cq, then add Xi with cost Ci into Cq; If Xi is in Cq, 989 then If Cxi > Ci then replace Xi with cost Cxi by Xi with Ci in 990 Cq; If Cxi == Ci then add Xi with cost Ci into Cq. 992 4. Suppose that node A is associated with a low order cost LCa which 993 is the low order cost from root R to node A and a high order cost 994 HCa which is the high order cost from R to A, node Xi (i = 1, 2, 995 ..., n) is connected to node A and not in the flooding topology 996 Ft and the real cost of the link between A and Xi is Ci (i=1, 2, 997 ..., n). Compute LCxi and HCxi: LCxi = LCa + Ci if both A and Xi 998 have flag F set to one, otherwise LCxi = LCa HCxi = HCa + Ci if A 999 or Xi does not have flag F set to one, otherwise HCxi = HCa If Xi 1000 is not in Cq, then add Xi associated with LCxi, HCxi and PH = A 1001 into Cq; If Xi associated with LCxi' and HCxi' and PHxi' is in 1002 Cq, then If HCxi' > HCxi then replace Xi with HCxi', LCxi' and 1003 PHxi' by Xi with HCxi, LCxi and PH=A in Cq; otherwise (i.e., 1004 HCxi' == HCxi) if LCxi' > LCxi , then replace Xi with HCxi', 1005 LCxi' and PHxi' by Xi with HCxi, LCxi and PH=A in Cq; otherwise 1006 (i.e., HCxi' == HCxi and LCxi' == LCxi) if PHxi' > PH, then 1007 replace Xi with HCxi', LCxi' and PHxi' by Xi with HCxi, LCxi and 1008 PH=A in Cq. 1010 5. Make sure Cq is in a special order. Suppose that Ai (i=1, 2, 1011 ..., m) are the nodes in Cq, HCai and LCai are low order cost and 1012 high order cost associated with Ai, and IDi is the ID of Ai. One 1013 order is that for any k = 1, 2, ..., m-1, HCak < HCaj (j = k+1) 1014 or HCak = HCaj and LCak < LCaj or HCak = HCaj and LCak = LCaj and 1015 IDk < IDj. Goto step 1. 1017 A.3. Connecting Leaves 1019 Suppose that we have a flooding topology Ft built by one of the 1020 algorithms described above. Ft is like a tree. We may connect k (k 1021 >=0) leaves to the tree to have a enhanced flooding topology with 1022 more connectivity. 1024 Suppose that there are m (0 < m) leaves directly connected to a node 1025 X on the flooding topology Ft. Select k (k <= m) leaves through 1026 using a deterministic algorithm or rule. One algorithm or rule is to 1027 select k leaves that have smaller or larger IDs (i.e., the IDs of 1028 these k leaves are smaller/bigger than the IDs of the other leaves 1029 directly connected to node X). Since every node has a unique ID, 1030 selecting k leaves with smaller or larger IDs is deterministic. 1032 If k = 1, the leaf selected has the smallest/largest node ID among 1033 the IDs of all the leaves directly connected to node X. 1035 For a selected leaf L directly connected to a node N in the flooding 1036 topology Ft, select a connection/adjacency to another node from node 1037 L in Ft through using a deterministic algorithm or rule. 1039 Suppose that leaf node L is directly connected to nodes Ni (i = 1040 1,2,...,s) in the flooding topology Ft via adjacencies and node Ni is 1041 not node N, IDi is the ID of node Ni, and Hi (i = 1,2,...,s) is the 1042 number of hops from node L to node Ni in the flooding topology Ft. 1044 One Algorithm or rule is to select the connection to node Nj (1 <= j 1045 <= s) such that Hj is the largest among H1, H2, ..., Hs. If there is 1046 another node Na ( 1 <= a <= s) and Hj = Ha, then select the one with 1047 smaller (or larger) node ID. That is that if Hj == Ha and IDj < IDa 1048 then select the connection to Nj for selecting the one with smaller 1049 node ID (or if Hj == Ha and IDj < IDa then select the connection to 1050 Na for selecting the one with larger node ID). 1052 Suppose that the number of connections in total between leaves 1053 selected and the nodes in the flooding topology Ft to be added is 1054 NLc. We may have a limit to NLc. 1056 Authors' Addresses 1058 Huaimo Chen 1059 Huawei Technologies 1060 Boston 1061 USA 1063 Email: huaimo.chen@huawei.com 1065 Dean Cheng 1066 Huawei Technologies 1067 Santa Clara 1068 USA 1070 Email: dean.cheng@huawei.com 1072 Mehmet Toy 1073 Verizon 1074 USA 1076 Email: mehmet.toy@verizon.com 1078 Yi Yang 1079 IBM 1080 Cary, NC 1081 United States of America 1083 Email: yyietf@gmail.com 1084 Aijun Wang 1085 China Telecom 1086 Beiqijia Town, Changping District 1087 Beijing 102209 1088 China 1090 Email: wangaj.bri@chinatelecom.cn 1092 Xufeng Liu 1093 Volta Networks 1094 McLean, VA 1095 USA 1097 Email: xufeng.liu.ietf@gmail.com 1099 Yanhe Fan 1100 Casa Systems 1101 USA 1103 Email: yfan@casa-systems.com 1105 Lei Liu 1106 USA 1108 Email: liulei.kddi@gmail.com