idnits 2.17.1 draft-ietf-lsr-isis-ttz-04.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 (September 29, 2021) is 939 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'R71' is mentioned on line 331, but not defined == Missing Reference: 'R73' is mentioned on line 332, but not defined == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 1025, but no explicit reference was found in the text == Unused Reference: 'RFC5029' is defined on line 1047, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 1055, but no explicit reference was found in the text == Unused Reference: 'RFC7142' is defined on line 1064, but no explicit reference was found in the text == Unused Reference: 'RFC8099' is defined on line 1068, but no explicit reference was found in the text == Unused Reference: 'Clos' is defined on line 1079, but no explicit reference was found in the text == Unused Reference: 'RFC5307' is defined on line 1084, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-lsr-dynamic-flooding-09 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Chen 3 Internet-Draft R. Li 4 Intended status: Experimental Futurewei 5 Expires: April 2, 2022 Y. Yang 6 IBM 7 A. Kumar S N 8 RtBrick 9 Y. Fan 10 Casa Systems 11 N. So 13 V. Liu 15 M. Toy 16 Verizon 17 L. Liu 18 Fujitsu 19 K. Makhijani 20 Futurewei 21 September 29, 2021 23 IS-IS Topology-Transparent Zone 24 draft-ietf-lsr-isis-ttz-04 26 Abstract 28 This document specifies a topology-transparent zone in an IS-IS area. 29 A zone is a subset (block/piece) of an area, which comprises a group 30 of routers and a number of circuits connecting them. It is 31 abstracted as a virtual entity such as a single virtual node or zone 32 edges mesh. Any router outside of the zone is not aware of the zone. 33 The information about the circuits and routers inside the zone is not 34 distributed to any router outside of the zone. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 2, 2022. 53 Copyright Notice 55 Copyright (c) 2021 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 72 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3. Zone Abstraction . . . . . . . . . . . . . . . . . . . . . . 5 75 3.1. Node Abstraction Model . . . . . . . . . . . . . . . . . 5 76 3.2. Mesh Abstraction Model . . . . . . . . . . . . . . . . . 6 77 4. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 6 78 4.1. Zone as a Single Node . . . . . . . . . . . . . . . . . . 6 79 4.1.1. An Example of Zone as a Single Node . . . . . . . . . 7 80 4.1.2. Zone Leader Election . . . . . . . . . . . . . . . . 9 81 4.1.3. LS Generation for Zone as a Single Node . . . . . . . 10 82 4.1.4. Adjacency Establishment . . . . . . . . . . . . . . . 10 83 4.1.5. Computation of Routes . . . . . . . . . . . . . . . . 11 84 4.2. Extensions to Protocols . . . . . . . . . . . . . . . . . 12 85 4.2.1. Zone ID TLV . . . . . . . . . . . . . . . . . . . . . 12 86 4.3. Zone as Edges Full Mesh . . . . . . . . . . . . . . . . . 14 87 4.3.1. An Example of Zone as Edges Full Mesh . . . . . . . . 14 88 4.3.2. Updating LSPs for Zone as Edges Full Mesh . . . . . . 15 89 4.3.3. Computation of Routes . . . . . . . . . . . . . . . . 16 90 4.4. Advertisement of LSPs . . . . . . . . . . . . . . . . . . 16 91 4.4.1. Advertisement of LSPs within Zone . . . . . . . . . . 16 92 4.4.2. Advertisement of LSPs through Zone . . . . . . . . . 17 93 5. Seamless Migration . . . . . . . . . . . . . . . . . . . . . 17 94 5.1. Transfer Zone to a Single Node . . . . . . . . . . . . . 17 95 5.2. Roll Back from Zone as a Single Node . . . . . . . . . . 18 97 6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 19 98 6.1. Configuring Zone . . . . . . . . . . . . . . . . . . . . 19 99 6.2. Transferring Zone to Node . . . . . . . . . . . . . . . . 20 100 6.3. Rolling back Node to Zone . . . . . . . . . . . . . . . . 20 101 7. Experiment Scope . . . . . . . . . . . . . . . . . . . . . . 21 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 103 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 104 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 105 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 22 106 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 107 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 108 12.2. Informative References . . . . . . . . . . . . . . . . . 24 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 111 1. Introduction 113 [ISO10589] and [RFC1195] describe two levels of areas in IS-IS, level 114 1 and level 2 areas. There are scalability issues in using areas as 115 the number of routers in a network becomes larger and larger. When 116 an IS-IS area becomes larger, its convergence on a network event such 117 as a link down will take a longer time. During the period of network 118 converging, more traffic that is transported through the network area 119 will get lost. 121 Through splitting the network into multiple level 1 areas connected 122 by level 2, we may extend the network further. However, dividing a 123 network from one area into multiple areas or from a number of 124 existing areas to even more areas can be a challenging and time 125 consuming task since it involves significant network architecture 126 changes. It needs a careful planning and many configurations on the 127 network. 129 These issues can be resolved by using topology-transparent zone 130 (TTZ), which abstracts a zone (i.e., a subset of an area) as a single 131 virtual node or zone edges' mesh with minimum efforts and minimum 132 service interruption. Note that a zone can be an entire area. 134 This document presents topology-transparent zone and specifies 135 extensions to IS-IS that support topology-transparent zone. 137 1.1. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119] [RFC8174] 142 when, and only when, they appear in all capitals, as shown here. 144 1.2. Terminology 146 Zone: A subset (block or piece) of an area. In a special case, a 147 zone is an entire area. 149 TTZ: Topology-Transparent Zone (TTZ) is a mechanism that abstracts a 150 zone as a single virtual node or zone edges' full mesh. The 151 virtual node appears connected to all the zone neighbors. 153 TTZ Virtual Entity: A single virtual node or zone edges' full mesh 154 to which a zone is transformed using TTZ. 156 A TTZ: A zone that is (to be) abstracted using TTZ. 158 Zone External Node: A node outside of a zone. 160 Zone Internal Node: A node within a zone without any connection to a 161 node outside of the zone. 163 Zone Edge/Border Node: A node that is part of a zone connecting to a 164 node outside of the zone. 166 Zone Node: A zone internal node or a zone edge/border node (i.e., a 167 node that is part of a zone). 169 Zone Link: A link connecting zone nodes (i.e., a link that is part 170 of a zone). 172 Zone Neighbor Node: A node outside of a zone that is a neighbor of 173 a zone edge/border node. 175 Zone Neighbor: A Zone Neighbor Node. 177 CLI: Command Line Interface. 179 LSP: A Link State Protocol Data Unit (PDU) in IS-IS. An LSP 180 contains link state information. In general, a router/node 181 originates multiple LSPs, distinguished by LSP fragment number, 182 to carry the link state information about it and the links 183 attached to it. 185 LS: Link State. In general, the LS for a node is all the LSPs that 186 the node originates. The LS for a zone is the set of LSPs that 187 all the nodes in the zone originate to carry the information 188 about them and the links attached to them inside the zone. 190 2. Requirements 192 Topology-Transparent Zone (TTZ) may be deployed to resolve some 193 critical issue of scalability in existing networks and future 194 networks. The requirements for TTZ are as follows: 196 o TTZ MUST be backward compatible. When a TTZ is deployed on a set 197 of routers in a network, the routers outside of the TTZ in the 198 network do not need to know or support TTZ. 200 o TTZ MUST support at least one more levels of network hierarchy, in 201 addition to the hierarchies supported by existing IS-IS. 203 o Transforming a zone (i.e., a block of network area) to a TTZ 204 virtual entity SHOULD be smooth with minimum service interruption. 205 A TTZ virtual entity is either a single virtual node or zone 206 edges' full mesh. 208 o Transforming (or say rolling back) a TTZ virtual entity back to 209 its zone (i.e., its original block of network area not using TTZ) 210 (refer to Section 5.2) SHOULD be smooth with minimum service 211 interruption. 213 o The configuration for a TTZ in a network SHOULD be minimal. 215 o The changes on the existing protocols to support TTZ SHOULD be 216 minimal. 218 3. Zone Abstraction 220 When abstracting a zone, a user may select one of two models: node 221 abstraction model and mesh abstraction model. 223 3.1. Node Abstraction Model 225 In node abstraction model (or node model for short), a zone is 226 abstracted as a single virtual node. The virtual node represents the 227 entire zone. It appears connected to all the zone neighbors and is 228 in the same area as those neighbors. 230 Deploying node model may cause changes on some routes since the block 231 of an area (zone) becomes a single virtual node. Some of the routes 232 that are optimal before the abstraction may be changed to be 233 suboptimal after the abstraction (refer to Section 4.1.5). This may 234 attract traffic to the TTZ and change the balance of traffic in the 235 network. 237 The advantage of node model is that it provides a higher degree of 238 abstraction rate than the mesh model. It is more scalable. 240 3.2. Mesh Abstraction Model 242 In mesh abstraction model (or mesh model for short), a zone is 243 abstracted as its edges' full mesh, there is a full mesh of 244 connections among the edges and each edge is also connected to its 245 neighbors outside of the zone. 247 The advantage of mesh model is that it keeps the routes unchanged. 248 After a zone is abstracted as the full mesh of the edges of the zone, 249 every route is still optimal (refer to Section 4.3.3). 251 The disadvantage of mesh model is that it does not scale when the 252 number of edge nodes of a zone is large. 254 4. Topology-Transparent Zone 256 A Topology-Transparent Zone (TTZ) comprises an Identifier (ID) and a 257 subset (piece/block) of an area such as a Level 2 area in IS-IS. It 258 is abstracted as a single virtual node or its edges' full mesh. TTZ 259 and zone as well as node and router will be used interchangeably 260 below. 262 A zone MUST be within a single area. In addition, all the nodes in a 263 zone MUST reside within a common level. There are three cases. All 264 the nodes in a zone are L1 nodes except for some of edge nodes of the 265 zone may be L1/L2 nodes. All the nodes in a zone are L2 nodes except 266 for some of edge nodes of the zone may be L1/L2 nodes. All the nodes 267 in a zone are L1/L2 nodes. 269 4.1. Zone as a Single Node 271 After a zone is abstracted as a single virtual node having a virtual 272 node ID, every node outside of the zone sees a number of links 273 connected to this single node. Each of these links connects to a 274 zone neighbor. The link states inside the zone are not advertised to 275 any node outside of the zone. The virtual node ID may be derived 276 from the zone ID. The value of the zone ID is transferred to four 277 bytes of an IPv4 address, and then to 12 digitals of the IPv4 address 278 in dotted form. The node ID of 6 bytes is from these 12 digitals, 2 279 digitals for 1 byte. 281 The sections below describe the behaviors of zone nodes when/after a 282 zone is abstracted to a single virtual node. They are summarized as 283 follows. 285 o Zone leader originates the LS (i.e., a set of LSPs) for the 286 virtual node (refer to Section 4.1.3). 288 o Zone nodes re-advertise the LS originated by the zone leader 289 (refer to Section 4.1.3 and Section 4.1.4). 291 o Zone edge/border node forms adjacencies with zone neighbor nodes 292 using the identity of the virtual node not its own identity (refer 293 to Section 4.1.4). 295 o Zone edge/border node re-advertises the LS for the virtual node as 296 it originates the LS (refer to Section 4.1.4). 298 o Zone edge/border node purges its existing LSP and originates a new 299 LSP containing its zone links after receiving the LS for the 300 virtual node (refer to Section 4.1.4). 302 o Zone edge/border nodes do not advertise the LSPs originated by 303 zone nodes to its zone neighbors (refer to Section 4.1.4 and 304 Section 4.4.1). 306 o Zone edge/border nodes continue to operate IS-IS as normal to 307 advertise the LSPs received from its zone neighbors (refer to 308 Section 4.1.4 and Section 4.4.2). 310 o Zone internal nodes continue to operate IS-IS as normal to 311 advertise the LSPs received from its neighbors (refer to 312 Section 4.4.1). 314 o Zone nodes compute routes from the topology without the virtual 315 node (refer to Section 4.1.5). 317 4.1.1. An Example of Zone as a Single Node 319 The figure below shows an example of an area containing a TTZ: TTZ 320 600. 322 TTZ 600 323 \ 324 \ ^~^~^~^~^~^~^~^~^~^~^~^~ 325 ( ) 326 ===[R15]========(==[R61]------------[R63]==)======[R29]=== 327 ||\ ( | \ / | ) || 328 || \ ( | \ / | ) || 329 || \___ ( | \ / | ) || 330 || \ ( | ___\ / | ) || 331 || \ ( | / [R71] | ) || 332 || \( | [R73] / \ | ) || 333 || (\ | / \ | ) || 334 || ( \ | / \ | ) || 335 || ( \| / \ | ) || 336 ===[R17]========(==[R65]------------[R67]==)======[R31]=== 337 \\ (// \\) // 338 || //v~v~v~v~v~v~v~v~v~v~v~\\ || 339 || // \\ || 340 || // \\ || 341 \\ // \\ // 342 ======[R23]==============================[R25]===== 343 // \\ 344 // \\ 346 Figure 1: An Example of TTZ 600 348 The area comprises routers R15, R17, R23, R25, R29 and R31. It also 349 contains TTZ 600, which comprises routers R61, R63, R65, R67, R71 and 350 R73, and the circuits connecting them. 352 There are two types of routers in a TTZ: TTZ internal routers and TTZ 353 edge/border routers. A TTZ internal router is a router inside the 354 TTZ and its adjacent routers are inside the TTZ. A TTZ edge/border 355 router is a router inside the TTZ and has at least one adjacent 356 router that is outside of the TTZ. 358 The TTZ in the figure above comprises four TTZ edge/border routers 359 R61, R63, R65 and R67. Each TTZ edge/border router is connected to 360 at least one router outside of the TTZ. For instance, router R61 is 361 a TTZ edge/border router since it is connected to router R15, which 362 is outside of the TTZ. 364 In addition, the TTZ comprises two TTZ internal routers R71 and R73. 365 A TTZ internal router is not connected to any router outside of the 366 TTZ. For instance, router R71 is a TTZ internal router since it is 367 not connected to any router outside of the TTZ. It is just connected 368 to routers R61, R63, R65, R67 and R73 inside the TTZ. 370 A TTZ MUST hide the information inside the TTZ from the outside. It 371 MUST NOT directly distribute any internal information about the TTZ 372 to a router outside of the TTZ. 374 From a router outside of the TTZ, a TTZ is seen as a single node 375 (refer to the Figure below). For instance, router R15, which is 376 outside of TTZ 600, sees TTZ 600 as a single node Rz, which has 377 normal connections to R15, R29, R17 and R23, R25 and R31. 379 TTZ 600 380 \ 381 \ ^~^~^~^~^~^~^~^~^~^~^~^~ 382 ( ) 383 ===[R15]========( )======[R29]=== 384 ||\ ( ) || 385 || \ ( ) || 386 || \ ( ) || 387 || \ ( ) || 388 || \ ( Rz ) || 389 || \ ( ) || 390 || \ ( ) || 391 || \ ( ) || 392 || \( ) || 393 ===[R17]========( )======[R31]=== 394 \\ ( ) // 395 || //v~v~v~v~v~v~v~v~v~v~v~\\ || 396 || // \\ || 397 || // \\ || 398 \\ // \\ // 399 ======[R23]==============================[R25]===== 400 // \\ 401 // \\ 403 Figure 2: TTZ 600 as Single Node Rz 405 4.1.2. Zone Leader Election 407 A node in a zone is elected as a leader for the zone, which is the 408 node with the highest priority (and the highest node ID when there 409 are more than one nodes having the same highest priority) in the 410 zone. The leader election mechanism described in 411 [I-D.ietf-lsr-dynamic-flooding] is used to elect the leader for the 412 zone. 414 4.1.3. LS Generation for Zone as a Single Node 416 The leader for the zone originates the LS (i.e., set of LSPs) for the 417 zone as a single virtual node and sends it to its neighbors. Each of 418 the nodes in the zone re-advertises the LS to all its neighbors 419 except for the one from which the LS is received. 421 This LS comprises all the adjacencies between the virtual node and 422 the zone neighbors. The System ID of each LSP ID is the ID of the 423 virtual node for the zone. The Source ID or Advertising Node/Router 424 ID is the ID of the virtual node. 426 In addition, this LS may contain the IP prefixes such as the loopback 427 IP addresses inside the zone to be accessed by zone external nodes 428 (i.e., nodes outside of the zone). These IP prefixes are included in 429 the IP internal reachability TLV. 431 When the existing zone leader fails, a new zone leader is elected. 432 The new leader originates the LSPs for the virtual node based on the 433 LSPs received from the failed leader. It retains the System ID of 434 each LSP ID and the live adjacencies between the virtual node and the 435 zone neighbors. 437 4.1.4. Adjacency Establishment 439 A zone edge node X, acting as a proxy for the single virtual node for 440 the zone, forms a new adjacency between the virtual node and a node Y 441 that is outside of the zone and in node X's area. There are two 442 cases. One case is that there is an existing adjacency between X and 443 Y; the other is that no adjacency exists between X and Y. 445 4.1.4.1. New Adjacency with Existing One 447 At first, zone edge node X acting as a proxy for the virtual node 448 creates a new adjacency between the virtual node for the zone and 449 node Y in a normal way. It sends Hellos and other packets containing 450 the virtual node ID as Source ID to node Y. Node Y establishes an 451 adjacency with the virtual node in the normal way. 453 Then, after receiving the LS for the virtual node originated by the 454 zone leader, node X does a number of things as follows. 456 It terminates the existing adjacency between node X and node Y. It 457 stops sending Hellos for the adjacency to node Y. Without receiving 458 Hellos from node X for a given time such as hold-timer interval, node 459 Y removes the adjacency to node X. Even though this adjacency 460 terminates, node X keeps the link to node Y in its LSP. 462 It stops advertising or readvertising the LSPs that are originated by 463 the zone nodes to node Y (also refer to Section 4.4.1). 465 It purges its current LSP and originates a new LSP containing its 466 zone links. The new LSP does not contain the information about the 467 adjacencies to the zone neighbors. It advertises the new LSP to its 468 neighbors in the zone (also refer to Section 4.4.1). It does not 469 advertise the new LSP to its zone neighbors. 471 It re-advertises the LS to all its neighbors except for the one from 472 which the LS is received. It re-advertises the LS to node Y as it 473 originates the LS. 475 It re-advertises the LSP received from zone neighbor Y to its other 476 neighbors, including the nodes in the zone, which re-advertise the 477 LSP (received from Y outside of the zone) as normal IS-IS protocol 478 operations (also refer to Section 4.4.2). 480 In the case where node Y is not in node X's area, is in the backbone 481 and connected to node X, node X, acting as a proxy for the virtual 482 node, creates a new adjacency between the virtual node and node Y in 483 a normal way and sends the LS for the virtual node to node Y if the 484 zone includes all the nodes in its area. 486 4.1.4.2. New Adjacency without Existing One 488 Every IS-IS protocol packet, such as Hello, that zone edge node X 489 originates and sends node Y, uses the virtual node ID as Source ID. 491 When node X synchronizes its link state database (LSDB) with node Y, 492 it sends Y all the link state information except for the link state 493 belonging to the zone that is hidden from the nodes outside of the 494 zone. 496 At the end of the LSDB synchronization, the LS for the zone as a 497 single virtual node is originated by the zone leader and distributed 498 to node Y. This LS contains the adjacencies between the virtual node 499 and all the zone neighbors, including this newly formed zone neighbor 500 Y. 502 Then node X has the same behaviors as those described above except 503 for terminating the existing adjacency and purging its existing LSP. 505 4.1.5. Computation of Routes 507 After a zone is transferred/migrated to a single virtual node, every 508 zone node computes the routes (i.e., shortest paths to the 509 destinations) using the graph consisting of the zone topology, the 510 connections between each zone edge and its zone neighbor, and the 511 topology outside of the zone without the virtual node. The metric of 512 a link outside of the zone is one order of magnitude larger than the 513 metric of a link inside the zone. 515 Every node outside the zone computes the routes using the topology 516 outside of the zone with the virtual node. The node does not have 517 the topology inside the zone. The metric of every link outside of 518 the zone is not changed. 520 4.2. Extensions to Protocols 522 This document defines a new TLV for use in IS-IS as follows. 524 o Zone ID TLV: containing a zone ID, a flags field and optional sub- 525 TLVs. 527 4.2.1. Zone ID TLV 529 The format of IS-IS Zone ID TLV is illustrated below. It MUST be 530 added into an LSP for a zone node. 532 0 1 2 3 533 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Type (TBD1) | Length | Zone ID | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Zone ID (Continue) | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | RESV |E| OP | Sub TLVs | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 541 ~ ~ 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 Figure 3: IS-IS Zone ID TLV 546 Type (1 byte): TBD1. 548 Length (1 byte): Its value is variable with a minimum of 8. A value 549 larger than 8 means that sub-TLVs are present. If length is less 550 than 8, the TLV MUST be ignored. 552 Zone ID (6 bytes): It is the identifier (ID) of a zone. 554 Flags field (16 bits): one flag bit E, OP of 3 bits, and a reserved 555 subfield are as follows: 557 RESV: Reserved. MUST be send as zero and ignored on receipt. 558 E = 1: Indicating a node is a zone edge node 559 E = 0: Indicating a node is a zone internal node 561 When a Zone ID is configured on a zone node (refer to Section 6.1), 562 the node updates its LSP by adding an IS-IS Zone ID TLV with the Zone 563 ID. If it is a zone internal node, the TLV has its flag E = 0; 564 otherwise (i.e., it is a zone edge node) the TLV has its flag E = 1 565 and includes a Zone ISN Sub TLV containing the zone links configured. 566 Every link of a zone internal node is a zone link. 568 OP Value Meaning (Operation) 569 0x001 (T): Advertising Zone Topology Information for Migration 570 0x010 (M): Migrating Zone to a Virtual Entity such as Virtual Node 571 0x011 (N): Advertising Normal Topology Information for Rollback 572 0x100 (R): Rolling Back from the Virtual Entity 574 The value of OP indicates one of the four operations above. When any 575 of the other values is received, the TLV MUST be ignored. 577 The first two values of OP (i.e., OP = 0x001 and OP = 0x010) are used 578 for transforming a zone to a TTZ virtual entity (refer to 579 Section 5.1). The last two values (i.e., OP = 0x011 and OP = 0x100) 580 are used for transforming (or say rolling back) the TTZ virtual 581 entity back to the zone (refer to Section 5.2). 583 Two new sub-TLVs are defined, which may be added to an IS-IS Zone ID 584 TLV. One is the Zone IS Neighbor sub-TLV, or Zone ISN sub-TLV for 585 short. The other is the Zone ES Neighbor sub-TLV, or Zone ESN sub- 586 TLV for short. A Zone ISN sub-TLV contains the information about a 587 number of IS neighbors in the zone connected to a zone edge node. It 588 has the format below. 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Type (1) | Length | Neighbor ID(i) | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 595 | | 596 + +-----------------------------------------------+ 597 | | Metric (i) | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 ~ ~ 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 Figure 4: Zone ISN Sub TLV 604 A Zone ISN Sub TLV has 1 byte of Type, 1 byte of Length of 605 n*(IDLength + 3), which is followed by n tuples of Neighbor ID and 606 Metric. 608 A Zone ESN sub-TLV contains the information about a number of ES 609 neighbors in the zone connected to a zone edge node. It has the 610 format below. 612 0 1 2 3 613 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 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Type (2) | Length | Neighbor ID(i) | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 617 | | 618 + +-----------------------------------------------+ 619 | | Metric (i) | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 ~ ~ 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 Figure 5: Zone ESN Sub TLV 626 After a zone ID is configured on a zone internal node (refer to 627 Section 6.1), the zone internal node includes a Zone ID TLV with the 628 zone ID and E = 0 in its LSP. The TLV indicates that the node 629 originates the TLV is a zone internal node and all its links are zone 630 links. 632 After a zone ID is configured on every zone link of a zone edge/ 633 border node (refer to Section 6.1), the zone edge/border node 634 includes a Zone ID TLV with the zone ID, E = 1, Zone ISN Sub TLV and 635 Zone ESN Sub TLV in its LSP. The TLV indicates that the node 636 originates the TLV is a zone edge/border node and all the links in 637 the Sub TLVs are zone links. 639 After all the zone nodes in a zone include their Zone ID TLVs in 640 their LSPs, the zone is determined from the point of view of LSDB. 642 4.3. Zone as Edges Full Mesh 644 4.3.1. An Example of Zone as Edges Full Mesh 646 The figure below illustrates an area from the point of view on a 647 router outside of TTZ 600 after TTZ 600 is created and abstracted as 648 its edges full mesh from Figure 1. 650 TTZ 600 651 \ 652 \ ^~^~^~^~^~^~^~^~^~^~^ 653 ( ) 654 ===[R15]========(==[R61]=========[R63]==)======[R29]=== 655 ||\ ( || \\ // || ) || 656 || \ ( || \\ // || ) || 657 || \ ( || \\ // || ) || 658 || \____ ( || \\// || ) || 659 || \( || //\ || ) || 660 || \ || // \\ || ) || 661 || (\ || // \\ || ) || 662 || ( \ || // \\ || ) || 663 || ( \|| // \\ || ) || 664 ===[R17]========(==[R65]=========[R67]==)=======[R31]=== 665 \\ (// \\) // 666 || //v~v~v~v~v~v~v~v~v~v\\ || 667 || // \\ || 668 || // \\ || 669 \\ // \\ // 670 ======[R23]============================[R25]===== 671 // \\ 672 // \\ 674 Figure 6: TTZ 600 as Edges Full Mesh 676 From a router outside of the TTZ, a TTZ is seen as the TTZ edge 677 routers connected each other. For instance, router R15 sees that 678 R61, R63, R65 and R67 are connected each other. The cost from one 679 edge router to another edge router is the cost of the shortest path 680 between these two routers. 682 The adjacencies between each of the TTZ's edge routers and its 683 neighbors outside the TTZ are not changed. A router outside of the 684 TTZ sees TTZ edge routers having their normal original connections to 685 the routers outside of the TTZ. For example, router R15 sees that 686 R61, R63, R65 and R67 have their normal original connections to R15, 687 R29, R17 and R23, R25 and R31 respectively. 689 4.3.2. Updating LSPs for Zone as Edges Full Mesh 691 For every zone edge node, it updates its LSP in three steps and 692 floods the LSP to all its neighbors. 694 At first, it adds each of the other zone edge nodes as an IS neighbor 695 into the Intermediate System Neighbors TLV in its LSP after it 696 receives an LSP containing an IS-IS Zone ID TLV with OP = M or a 697 command activating migration zone to a TTZ virtual entity. The 698 metric to the neighbor is the metric of the shortest path to the edge 699 node within the zone. 701 In addition, it adds an IP internal reachability TLV into its LSP. 702 The TLV contains a number of IP prefixes in the zone to be reachable 703 from outside of the zone. 705 And then it removes the IS neighbors corresponding to the IS 706 neighbors in the Zone ID TLV (i.e., in the Zone ISN sub TLV) from 707 Intermediate System Neighbors TLV in its LSP, and the ES neighbors 708 corresponding to the ES neighbors in the Zone ID TLV (i.e., in the 709 Zone ESN sub TLV) from End System Neighbors TLV in the LSP. This 710 SHOULD be done after it receives the LSPs for virtualizing zone from 711 the other zone edges for a given time. 713 4.3.3. Computation of Routes 715 After a zone is transferred/migrated to the zone edges' full mesh, 716 every zone node computes the routes (i.e., shortest paths to the 717 destinations) using the graph consisting of the zone topology and the 718 topology outside of the zone without the full mesh. Every node 719 outside the zone computes the routes using the topology outside of 720 the zone with the full mesh. The metric of every link inside and 721 outside of the zone is not changed. 723 4.4. Advertisement of LSPs 725 LSPs can be divided into a couple of classes according to their 726 Advertisements. The first class of LSPs is advertised within a zone. 727 The second is advertised through a zone. 729 4.4.1. Advertisement of LSPs within Zone 731 Any LSP about a link state in a zone is advertised only within the 732 zone. It is not advertised to any router outside of the zone. For 733 example, a LSP generated for a zone internal node is advertised only 734 within the zone. 736 Any LSP generated for a broadcast network in a zone is advertised 737 only within the zone. It is not advertised outside of the zone. 739 After migrating to a zone as a single virtual node or edges' full 740 mesh, every zone edge MUST NOT advertise any LSP belonging to the 741 zone or any information in a LSP belonging to the zone to any node 742 outside of the zone. The zone edge determines whether an LSP is 743 about a zone internal link state by checking if the originating node 744 of the LSP is a zone internal node. 746 For any LSP originated by a node within the zone, every zone edge 747 node MUST NOT advertise it to any node outside of the zone. 749 4.4.2. Advertisement of LSPs through Zone 751 Any LSP about a link state outside of a zone received by a zone edge 752 is advertised using the zone as transit. For example, when a zone 753 edge node receives an LSP from a node outside of the zone, it floods 754 the LSP to its neighbors both inside and outside of the zone. 756 The nodes in the zone continue to flood the LSP. When another zone 757 edge receives the LSP, it floods the LSP to its neighbors both inside 758 and outside of the zone. 760 5. Seamless Migration 762 This section presents the seamless migration between a zone and its 763 single virtual node. 765 5.1. Transfer Zone to a Single Node 767 Transferring a zone to a single virtual node smoothly takes a few 768 steps or stages. 770 At first, a user configures the zone on every node of the zone (refer 771 to Section 6.1). Every zone node updates its LSP by including a Zone 772 ID TLV. For a zone edge node, the TLV has the Zone ID configured, 773 its flag E = 1 and a Zone ISN Sub TLV containing the zone links 774 configured. For a zone internal node, the TLV has the Zone ID 775 configured and its flag E = 0. 777 Second, after finishing the configuration of the zone, a user may 778 issue a command, such as a CLI command, on a zone node, such as the 779 zone leader, to trigger transferring the zone to the single virtual 780 node. When the node receives the command, it updates its LSP by 781 setting OP = T in its Zone ID TLV, which is distributed to every zone 782 node. After receiving the Zone ID TLV with OP = T, every zone edge 783 node, acting as a proxy of the virtual node, establishes a new 784 adjacency between the virtual node and each of its zone neighbor 785 nodes. 787 The command may be replaced by the determination made by a zone node, 788 such as the zone leader. After determining that the configuration of 789 the zone is finished for a given time such as 10 seconds, it updates 790 its LSP by setting OP = T in its Zone ID TLV. The configuration is 791 complete if every zone link configured is bidirectional. For every 792 zone internal node configured with the Zone ID, there is an LSP 793 containing its Zone ID TLV with E = 0 in the LSDB, which indicates 794 that each link from the node (one direction) is a zone link. For 795 every zone edge node, each of its zone links configured from the edge 796 node (one direction) is included in its LSP containing its Zone ID 797 TLV with E = 1 and Zone ISN Sub TLV in the LSDB. 799 Third, after receiving the updated LSPs from all the zone neighbor 800 nodes, the zone leader checks if all the new adjacencies between the 801 virtual node and the zone neighbor nodes have been established. If 802 so, it originates an LS for the virtual node and updates its LSP 803 (i.e., the LSP for itself zone leader) by setting OP = M in its Zone 804 ID TLV, which is distributed to every zone node. 806 After receiving the LS for the virtual node or the Zone ID TLV with 807 OP = M, every zone node migrates to zone as virtual node. Every zone 808 edge node does not send any LS inside the zone to any zone neighbors. 809 It advertises its LSP without any zone links to the nodes outside of 810 the zone or purges its LSP outside of the zone, terminates its 811 adjacency to each of its zone neighbors, but contains the adjacency 812 in its LSP that is distributed within the zone. Every zone node 813 computes the routes according to Section 4.1.5. 815 5.2. Roll Back from Zone as a Single Node 817 After abstracting a zone to a single virtual node, we may want to 818 roll back the node to the zone smoothly in some cases. The process 819 of rolling back has a few steps or stages. 821 At first, a user issues a command, such as a CLI command, on a zone 822 node, such as the zone leader, to start (or prepare) for roll back. 823 When receiving the command, the node triggers the preparation for 824 roll back through updating its LSP by setting OP = N in its Zone ID 825 TLV, which will be distributed to every node in the zone. After 826 receiving the Zone ID TLV with OP = N, every zone edge node 827 establishes a normal adjacency between the edge node and each of its 828 zone neighbor nodes, and advertises the link state of the zone over 829 the adjacency if it crosses the adjacency, but holds off its LSP 830 containing the normal adjacency. 832 Second, a user may issue a command, such as a CLI command, on a zone 833 node, such as the zone leader, to roll back from the virtual node to 834 the zone if the following conditions are met. 836 Condition 1: All the normal adjacencies between every zone edge node 837 and each of its zone neighbor nodes have been established. 839 Condition 2: All the link state about the zone that is supposed to 840 be advertised outside of the zone has been advertised. 842 After receiving the command, the node updates its LSP by setting OP = 843 R in its Zone ID TLV, which is distributed to every zone node. After 844 receiving the Zone ID TLV with OP = R, 846 o every zone edge node, acting as a proxy of the virtual node, 847 terminates the adjacency between the virtual node and each of its 848 zone neighbor nodes and advertises its LSP containing the normal 849 adjacencies between it and each of its zone neighbor nodes; 851 o The zone leader purges the LS for the virtual node abstracted from 852 the zone; and 854 o Every zone node rolls back to normal. 856 The command may be replaced by the determination made by a zone node, 857 such as the zone leader. After determining that all the conditions 858 are met, it updates its LSP by setting OP = R in its Zone ID TLV, 859 which is distributed to every zone node. 861 Condition 1 is met if it has its LSDB containing the link from each 862 zone neighbor node to its zone edge node. That is that for every 863 link from a zone neighbor node to the virtual node in the LSDB, there 864 is a corresponding link from the zone neighbor to a zone edge node. 866 Condition 2 is met after Condition 1 has been met for a given time, 867 such as maximum LSP advertisement time (MaxLSPAdvTime) crossing a 868 network. We may assume that MaxLSPAdvTime is 5 seconds. 870 6. Operations 872 6.1. Configuring Zone 874 In general, a zone is a subset of an area and has a zone ID. It 875 consists of some zone internal nodes and zone edge nodes. To 876 configure it, a user configures this zone ID on every zone internal 877 node and on every zone link of each zone edge node. A zone ID MUST 878 be unique in an AS. It MUST NOT be any IP address in the AS from 879 which a system ID is transformed to and used. 881 When the configuration of the zone ID is not consistent across the 882 zone, some unexpected results will be generated. For example, when 883 two different zone IDs are configured for the zone, two virtual nodes 884 for two zones may be seen in the network. These are not expected. 885 Once the unexpected results are seen, the inconsistent configurations 886 MUST be fixed. 888 A node configured with the zone ID has all its links to be the zone 889 links. The zone internal nodes and all their links plus the zone 890 edge nodes and their zone links constitute the zone. 892 In a special case, a zone is an entire area and has a zone ID. All 893 the links in the area are the zone links of the zone. To configure 894 this zone, a user configures the zone ID on every zone node. 896 6.2. Transferring Zone to Node 898 Transferring a zone to a single virtual node smoothly may take a few 899 steps or stages. 901 At first, a user configures the zone on every node of the zone. 903 After finishing the configuration of the zone, the user may issue a 904 command, such as a CLI command, on a zone node, such as the zone 905 leader, to trigger transferring the zone to the node (refer to 906 Section 5.1). 908 If automatic transferring zone to node is enabled, the user does not 909 need to issue the command. A zone node, such as the zone leader, 910 will trigger transferring the zone to the node after determining that 911 the configuration of the zone has been finished. 913 Then, all the zone nodes, including the zone leader, zone edge nodes 914 and zone internal nodes, work together to make the zone to appear as 915 a single virtual node smoothly in a couple of steps. 917 6.3. Rolling back Node to Zone 919 After abstracting a zone to a single virtual node, we may want to 920 roll back the node to the zone smoothly in some cases. The process 921 of rolling back has a few steps or stages. 923 At first, a user issues a command, such as a CLI command, on a zone 924 node, such as the zone leader, to start (or prepare) for roll back. 925 When receiving the command, the node triggers the preparation for 926 roll back (refer to Section 5.2). 928 Second, a user may issue a command, such as a CLI command, on a zone 929 node, such as the zone leader, to roll back from the virtual node to 930 the zone if it is ready for roll back (refer to Section 5.2). 932 If automatic roll back Node to Zone is enabled, the user does not 933 need to issue the command. A zone node, such as the zone leader, 934 will trigger the roll back after determining that it is ready for 935 roll back. 937 7. Experiment Scope 939 The experiment on TTZ should focus on node model. The experiment on 940 TTZ mesh model in OSPF has been done. The experiment includes the 941 aspects as follows. 943 o Abstraction. A zone (i.e., a block of an area not using TTZ) is 944 abstracted as a single virtual node. The size of the LSDB for the 945 area is reduced. Every node outside of the zone will see the 946 virtual node and the other nodes outside of the zone after the 947 abstraction. It will not see any node in the zone including the 948 edge nodes of the zone. 950 o Separation. Any node that is not participating in a zone does not 951 need to know or support TTZ. 953 o Safety. When a zone is configured correctly, neither zone edge 954 node or zone internal node breaches after the zone is abstracted 955 as a single virtual node. 957 o Alarm on Misconfiguration. Some critical misconfigurations should 958 be detected and alarmed. 960 8. Security Considerations 962 The mechanism described in this document does not raise any new 963 security issues for the IS-IS protocols. It is possible that an 964 attacker may become or act as a zone leader and inject bad LSPs for 965 the zone into the network, which disturbs the operations on the 966 network, especially the IS-IS protocols. Authentication methods 967 described in [RFC5304] and [RFC5310] SHOULD be used to prevent such 968 attack. 970 9. IANA Considerations 972 IANA is requested to make a new allocation in the "IS-IS TLV 973 Codepoint Registry" under the registry name "IS-IS TLV Codepoints" as 974 follows: 976 +==============+===================+=====================+ 977 | TLV Type | TLV Name | reference | 978 +==============+===================+=====================+ 979 | TBD1 | Zone ID | This document | 980 +--------------+-------------------+---------------------+ 981 Note that TBD1 is less than 255. 983 IANA is requested to create a new sub-registry "Sub-TLVs for TLV type 984 TBD1 (Zone ID TLV)" on the IANA IS-IS TLV Codepoints web page as 985 follows: 987 +==============+===================+=====================+ 988 | Type | Name | reference | 989 +==============+===================+=====================+ 990 | 0 | Reserved | 991 +--------------+-------------------+---------------------+ 992 | 1 | Zone ISN | This document | 993 +--------------+-------------------+---------------------+ 994 | 2 | Zone ESN | This document | 995 +--------------+-------------------+---------------------+ 996 | 3 - 255 | Unassigned | 997 +--------------+-------------------+---------------------+ 999 10. Contributors 1001 Alvaro Retana 1002 Futurewei 1003 Raleigh, NC 1004 USA 1006 Email: alvaro.retana@futurewei.com 1008 11. Acknowledgement 1010 The authors would like to thank Acee Lindem, Adrian Farrel, Abhay 1011 Roy, Christian Hopps, Dean Cheng, Russ White, Tony Przygienda, Wenhu 1012 Lu, Lin Han, Donald Eastlake, Tony Li, Robert Raszuk, Padmadevi 1013 Pillay Esnault, and Yang Yu for their valuable comments on TTZ. 1015 12. References 1017 12.1. Normative References 1019 [I-D.ietf-lsr-dynamic-flooding] 1020 Li, T., Psenak, P., Ginsberg, L., Chen, H., Przygienda, 1021 T., Cooper, D., Jalil, L., Dontula, S., and G. S. Mishra, 1022 "Dynamic Flooding on Dense Graphs", draft-ietf-lsr- 1023 dynamic-flooding-09 (work in progress), June 2021. 1025 [I-D.ietf-spring-segment-routing] 1026 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1027 Litkowski, S., and R. Shakir, "Segment Routing 1028 Architecture", draft-ietf-spring-segment-routing-15 (work 1029 in progress), January 2018. 1031 [ISO10589] 1032 International Organization for Standardization, 1033 "Intermediate System to Intermediate System Intra-Domain 1034 Routing Exchange Protocol for use in Conjunction with the 1035 Protocol for Providing the Connectionless-mode Network 1036 Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 2002. 1038 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1039 dual environments", RFC 1195, DOI 10.17487/RFC1195, 1040 December 1990, . 1042 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1043 Requirement Levels", BCP 14, RFC 2119, 1044 DOI 10.17487/RFC2119, March 1997, 1045 . 1047 [RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link 1048 Attribute Sub-TLV", RFC 5029, DOI 10.17487/RFC5029, 1049 September 2007, . 1051 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 1052 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 1053 2008, . 1055 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1056 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1057 2008, . 1059 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1060 and M. Fanto, "IS-IS Generic Cryptographic 1061 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 1062 2009, . 1064 [RFC7142] Shand, M. and L. Ginsberg, "Reclassification of RFC 1142 1065 to Historic", RFC 7142, DOI 10.17487/RFC7142, February 1066 2014, . 1068 [RFC8099] Chen, H., Li, R., Retana, A., Yang, Y., and Z. Liu, "OSPF 1069 Topology-Transparent Zone", RFC 8099, 1070 DOI 10.17487/RFC8099, February 2017, 1071 . 1073 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1074 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1075 May 2017, . 1077 12.2. Informative References 1079 [Clos] Clos, C., "A Study of Non-Blocking Switching Networks", 1080 The Bell System Technical Journal Vol. 32(2), DOI 1081 10.1002/j.1538-7305.1953.tb01433.x, March 1953, 1082 . 1084 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 1085 in Support of Generalized Multi-Protocol Label Switching 1086 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 1087 . 1089 Authors' Addresses 1091 Huaimo Chen 1092 Futurewei 1093 Boston, MA 1094 USA 1096 Email: huaimo.chen@futurewei.com 1098 Richard Li 1099 Futurewei 1100 2330 Central expressway 1101 Santa Clara, CA 1102 USA 1104 Email: richard.li@futurewei.com 1106 Yi Yang 1107 IBM 1108 Cary, NC 1109 United States of America 1111 Email: yyietf@gmail.com 1113 Anil Kumar S N 1114 RtBrick 1115 Bangalore 1116 India 1118 Email: anil.ietf@gmail.com 1119 Yanhe Fan 1120 Casa Systems 1121 USA 1123 Email: yfan@casa-systems.com 1125 Ning So 1126 Plano, TX 75082 1127 USA 1129 Email: ningso01@gmail.com 1131 Vic Liu 1132 USA 1134 Email: liu.cmri@gmail.com 1136 Mehmet Toy 1137 Verizon 1138 USA 1140 Email: mehmet.toy@verizon.com 1142 Lei Liu 1143 Fujitsu 1144 USA 1146 Email: liulei.kddi@gmail.com 1148 Kiran Makhijani 1149 Futurewei 1150 USA 1152 Email: kiranm@futurewei.com