idnits 2.17.00 (12 Aug 2021) /tmp/idnits27418/draft-dong-lsr-sr-enhanced-vpn-07.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 document date (30 January 2022) is 104 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) == Missing Reference: 'RFC5305' is mentioned on line 584, but not defined == Missing Reference: 'RFC5311' is mentioned on line 594, but not defined == Missing Reference: 'RFC5316' is mentioned on line 590, but not defined == Missing Reference: 'RFC5308' is mentioned on line 542, but not defined == Outdated reference: A later version (-19) exists of draft-ietf-lsr-flex-algo-18 == Outdated reference: A later version (-04) exists of draft-ietf-spring-resource-aware-segments-03 == Outdated reference: A later version (-02) exists of draft-ietf-spring-sr-for-enhanced-vpn-01 ** Downref: Normative reference to an Informational draft: draft-ietf-spring-sr-for-enhanced-vpn (ref. 'I-D.ietf-spring-sr-for-enhanced-vpn') == Outdated reference: A later version (-10) exists of draft-ietf-teas-enhanced-vpn-09 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-enhanced-vpn (ref. 'I-D.ietf-teas-enhanced-vpn') == Outdated reference: A later version (-01) exists of draft-dong-teas-nrp-scalability-00 == Outdated reference: A later version (-02) exists of draft-li-mpls-enhanced-vpn-vtn-id-01 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group J. Dong 3 Internet-Draft Z. Hu 4 Intended status: Standards Track Z. Li 5 Expires: 3 August 2022 Huawei Technologies 6 X. Tang 7 R. Pang 8 China Unicom 9 L. JooHeon 10 LG U+ 11 S. Bryant 12 Futurewei Technologies 13 30 January 2022 15 IGP Extensions for Scalable Segment Routing based Enhanced VPN 16 draft-dong-lsr-sr-enhanced-vpn-07 18 Abstract 20 Enhanced VPN (VPN+) aims to provide enhanced VPN services to support 21 some application's needs of enhanced isolation and stringent 22 performance requirements. VPN+ requires integration between the 23 overlay VPN connectivity and the characteristics provided by the 24 underlay network. A Virtual Transport Network (VTN) is a virtual 25 underlay network which has a customized network topology and a set of 26 network resources allocated from the physical network. A VTN could 27 be used to support one or a group of VPN+ services. 29 This document specifies the IGP mechanisms with necessary extensions 30 to advertise the associated topology and resource attributes for 31 scalable Segment Routing (SR) based VTNs. Each VTN can have a 32 customized topology and a set of network resources allocated from the 33 physical network. Multiple VTNs may shared the same topology, and 34 multiple VTNs may share the same set of network resources on some 35 network segments. A group of resource-aware SIDs are allocated for 36 each VTN. This allows flexible combination of the network topology 37 and network resource attributes to build a relatively large number of 38 VTNs with a small number of logical topologies. The proposed 39 mechanism is applicable to both Segment Routing with MPLS data plane 40 (SR-MPLS) and segment routing with IPv6 data plane (SRv6). This 41 document also describes the mechanisms of using dedicated VTN-ID in 42 the data plane instead of the per-VTN resource-aware SIDs to further 43 reduce the control plane overhead. 45 Requirements Language 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC 2119 [RFC2119]. 50 Status of This Memo 52 This Internet-Draft is submitted in full conformance with the 53 provisions of BCP 78 and BCP 79. 55 Internet-Drafts are working documents of the Internet Engineering 56 Task Force (IETF). Note that other groups may also distribute 57 working documents as Internet-Drafts. The list of current Internet- 58 Drafts is at https://datatracker.ietf.org/drafts/current/. 60 Internet-Drafts are draft documents valid for a maximum of six months 61 and may be updated, replaced, or obsoleted by other documents at any 62 time. It is inappropriate to use Internet-Drafts as reference 63 material or to cite them other than as "work in progress." 65 This Internet-Draft will expire on 3 August 2022. 67 Copyright Notice 69 Copyright (c) 2022 IETF Trust and the persons identified as the 70 document authors. All rights reserved. 72 This document is subject to BCP 78 and the IETF Trust's Legal 73 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 74 license-info) in effect on the date of publication of this document. 75 Please review these documents carefully, as they describe your rights 76 and restrictions with respect to this document. Code Components 77 extracted from this document must include Revised BSD License text as 78 described in Section 4.e of the Trust Legal Provisions and are 79 provided without warranty as described in the Revised BSD License. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 84 2. VTN Definition Advertisement . . . . . . . . . . . . . . . . 4 85 3. Advertisement of VTN Topology Attribute . . . . . . . . . . . 6 86 3.1. MTR based Topology Advertisement . . . . . . . . . . . . 6 87 3.2. Flex-Algo based Topology Advertisement . . . . . . . . . 7 88 4. Advertisement of VTN Resource Attribute . . . . . . . . . . . 8 89 4.1. Option 1: L2 Bundle based Approach . . . . . . . . . . . 8 90 4.2. Option 2: Per-VTN Link TE Attributes . . . . . . . . . . 10 91 5. Advertisement of VTN specific Data Plane Identifiers . . . . 12 92 5.1. Advertisement of VTN-specific SR-MPLS SIDs . . . . . . . 12 93 5.2. Advertisement of VTN-specific SRv6 Locators and SIDs . . 14 94 5.2.1. VTN-specific SRv6 Locators and End SIDs . . . . . . . 14 95 5.2.2. VTN-specific SRv6 End.X SIDs . . . . . . . . . . . . 17 96 5.3. Advertisement of Dedicated Data Plane VTN IDs . . . . . . 17 97 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 99 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 100 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 102 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 103 10.2. Informative References . . . . . . . . . . . . . . . . . 21 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 106 1. Introduction 108 Enhanced VPN (VPN+) is an enhancement to VPN services to support the 109 needs of new applications, particularly the applications that are 110 associated with 5G services. These applications require enhanced 111 isolation and have more stringent performance requirements than that 112 can be provided with traditional overlay VPNs. These properties 113 require integration between the underlay and the overlay networks. 114 [I-D.ietf-teas-enhanced-vpn] specifies the framework of enhanced VPN 115 and describes the candidate component technologies in different 116 network planes and layers. An enhanced VPN can be used for 5G 117 network slicing, and will also be of use in more generic scenarios. 119 To meet the requirement of different enhanced VPN services, a number 120 of virtual underlay networks need to be created, each with a 121 customized network topology and a set of network resources allocated 122 from the physical network to meet the requirement of one or a group 123 of VPN+ services. Such a virtual underlay network is called Virtual 124 Transport Network (VTN) in [I-D.ietf-teas-enhanced-vpn]. 126 [I-D.ietf-spring-resource-aware-segments] introduces resource-aware 127 segments by associating existing type of SIDs with network resource 128 attributes (e.g. bandwidth, processing or storage resources). These 129 resource-aware SIDs retain their original functionality, with the 130 additional semantics of identifying the set of network resources 131 available for the packet processing 132 action.[I-D.ietf-spring-sr-for-enhanced-vpn] describes the use of 133 resource-aware segments to build SR based VTNs. To allow the network 134 controller and network nodes to perform VTN-specific explicit path 135 computation and/or shortest path computation, the group of resource- 136 aware SIDs allocated by network nodes to each VTN and the associated 137 topology and resource attributes need to be distributed using the 138 control plane. 140 [I-D.dong-teas-nrp-scalability] analyzes the scalability requirements 141 and the control plane and data plane scalability considerations of 142 enhanced VPN, more specifically, the scalability of the VTNs. In 143 order to support a relatively large number of VTNs in the network, 144 one proposed approach is to separate the topology and resource 145 attributes of the VTN in control plane, so that the advertisement and 146 processing of each type of attribute could be decoupled. Multiple 147 VTNs may shared the same topology, and multiple VTNs may share the 148 same set of network resources on some network segments, while the 149 difference in either the topology or resource attributes makes them 150 different VTNs. This allows flexible combination of network topology 151 and network resource attributes to build a large number of VTNs with 152 a relatively small number of logical topologies. 154 This document specifies the IGP control plane mechanisms with 155 necessary extensions for scalable SR based VTNs. The proposed 156 mechanism is applicable to both segment routing with MPLS data plane 157 (SR-MPLS) and segment routing with IPv6 data plane (SRv6). This 158 document also describes the mechanisms of using dedicated VTN-ID in 159 the data plane instead of the per-VTN resource-aware SIDs to further 160 reduce the control plane overhead. 162 In general this approach applies to both IS-IS and OSPF, while the 163 specific protocol extensions and encodings are different. In the 164 current version of this document, the required IS-IS extensions are 165 described. The required OSPF extensions will be described in a 166 future version or in a separate document. 168 2. VTN Definition Advertisement 170 According to [I-D.ietf-teas-enhanced-vpn], a VTN is associated with a 171 customized network topology and a set of dedicated or shared network 172 resources. Thus a VTN can be defined as the combination of a set of 173 network attributes, which include the topology attribute and other 174 attributes, such as the network resources. IS-IS Virtual Transport 175 Network Definition (VTND) sub-TLV is used to advertise the definition 176 of a VTN. It is a sub-TLV of the IS-IS Router-Capability TLV 242 as 177 defined in [RFC7981]. 179 The format of IS-IS VTND sub-TLV is as below: 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Type | Length | VTN ID | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | VTN ID (Continue) | MT-ID | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Algorithm | Flags | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | | 191 ~ Sub-sub-TLVs ~ 192 | | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Where: 197 * Type: TBD 199 * Length: The length of the value field of the sub-TLV. It is 200 variable dependent on the included sub-TLVs. 202 * VTN ID: A global significant 32-bit identifier which is used to 203 identify a VTN. 205 * MT-ID: 16-bit field which indicates the multi-topology identifier 206 as defined in [RFC5120]. The first 4-bit are set to zero. 208 * Algorithm: 8-bit identifier which indicates the algorithm which 209 applies to this VTN. It can be either a normal algorithm 210 [RFC8402] or a Flexible Algorithm [I-D.ietf-lsr-flex-algo]. 212 * Flags: 8-bit flags. Currently all the flags are reserved for 213 future use. They SHOULD be set to zero on transmission and MUST 214 be ignored on receipt. 216 * Sub-sub-TLVs: optional sub-sub-TLVs to specify the additional 217 attributes of a VTN. Currently no sub-sub-TLV is defined in this 218 document. 220 The VTND Sub-TLV MAY be advertised in an LSP of any number. A node 221 MUST NOT advertise more than one VTND Sub-TLV for a given VTN ID. 223 3. Advertisement of VTN Topology Attribute 225 This section describes the mechanisms used to advertise the topology 226 attribute associated with SR based VTNs. Basically the topology of a 227 VTN can be determined by the MT-ID and/or the algorithm ID included 228 in the VTN definition. In practice, it could be described using two 229 optional approaches. 231 The first approach is to use Multi-Topology Routing (MTR) [RFC4915] 232 [RFC5120] with the segment routing extensions to advertise the 233 topology associated with the SR based VTNs. Different algorithms MAY 234 be used to further specify the computation algorithm or the metric 235 type used for path computation within the topology. Multiple VTNs 236 can be associated with the same , and the IGP 237 computation with the tuple can be shared by 238 these VTNs. 240 The second approach is to use Flex-Algo [I-D.ietf-lsr-flex-algo] to 241 describe the topological constraints of SR based VTNs on a shared 242 network topology (e.g. the default topology). Multiple VTNs can be 243 associated with the same Flex-Algo, and the IGP computation with this 244 Flex-Algo can be shared by these VTNs. 246 3.1. MTR based Topology Advertisement 248 Multi-Topology Routing (MTR) has been defined in [RFC4915] and 249 [RFC5120] to create different network topologies in one network. It 250 also has the capability of specifying customized attributes for each 251 topology. The traditional use cases of multi-topology are to 252 maintain separate topologies for unicast and multicast services, or 253 to create different topologies for IPv4 and IPv6 in a network. There 254 are some limitations when MTR is used with native IP forwarding, the 255 considerations about MT based IP forwarding are described in 256 [RFC5120]. 258 MTR can be used with SR-MPLS data plane. [RFC8667] specifies the IS- 259 IS extensions to support SR-MPLS data plane, in which the Prefix-SID 260 sub-TLVs can be carried in IS-IS TLV 235 (MT IP Reachability) and TLV 261 237 (MT IPv6 IP Reachability), and the Adj-SID sub-TLVs can be 262 carried in IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor 263 Attribute). 265 MTR can also be used with SRv6 data plane. 266 [I-D.ietf-lsr-isis-srv6-extensions] specifies the IS-IS extensions to 267 support SRv6 data plane, in which the MT-ID is carried in the SRv6 268 Locator TLV. The SRv6 End SIDs are carried as sub-TLVs in the SRv6 269 Locator TLV, and inherit the topology/algorithm from the parent 270 locator. The SRv6 End.X SIDs are carried as sub-TLVs in the IS-IS 271 TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor Attribute), and inherit 272 the topology/algorithm from the parent locator. 274 These IGP extensions for SR-MPLS and SRv6 can be used to advertise 275 and build the topology for a group of SR based VTNs. 277 An algorithm ID MAY be used to further specify the computation 278 algorithm or the metric type used for path computation within the 279 topology. 281 3.2. Flex-Algo based Topology Advertisement 283 [I-D.ietf-lsr-flex-algo] specifies the mechanisms to provide 284 distributed computation of constraint-based paths, and how the SR- 285 MPLS prefix-SIDs and SRv6 locators can be used to steer packets along 286 the constraint-based paths. 288 The Flex-Algo Definition (FAD) can be used to describe the 289 topological constraints for path computation on a network topology. 290 According to the network nodes' participation of a Flex-Algo, and the 291 rules of including or excluding specific Administrative Groups 292 (colors) and the Shared Risk Link Groups (SRLGs), the topology of a 293 VTN can be determined using the associated Flex-Algo on a particular 294 topology (e.g. the default topology). 296 With the mechanisms defined in[RFC8667] [I-D.ietf-lsr-flex-algo], 297 prefix-SID advertisement can be associated with a tuple, in which the algorithm can be a Flex-Algo. This 299 allows network nodes to use the prefix-SID to steer traffic along 300 distributed computed paths according to the identified Flex-Algo in 301 the topology. 303 [I-D.ietf-lsr-isis-srv6-extensions] specifies the IS-IS extensions to 304 support SRv6 data plane, in which the SRv6 locators advertisement can 305 be associated with a specific topology and a specific algorithm, 306 which can be a Flex-Algo. With the mechanism defined in 307 [I-D.ietf-lsr-flex-algo], The SRv6 locator can be used to steer 308 traffic along distributed computed paths according to the identified 309 Flex-Algo in the topology. In addition, topology/algorithm specific 310 SRv6 End SID and End.X SID can be used to enforce traffic over the 311 LFA computed backup path. 313 Multiple Flex-Algos MAY be defined to describe the topological 314 constraints on a shared network topology (e.g. the default topology). 316 4. Advertisement of VTN Resource Attribute 318 This section specifies the mechanisms to advertise the network 319 resource attributes associated with the VTNs. The mechanism of 320 advertising the link resources and attributes associated with VTNs is 321 described. The mechanism of advertising node resources and 322 attributes associated with VTNs are for further study. Two optional 323 approaches are described in the following sub-sections: the first 324 option is the L2 Bundle [RFC8668] based approach, the second option 325 is to extend IGP to advertise per-VTN link TE attributes. 327 4.1. Option 1: L2 Bundle based Approach 329 On a Layer-3 interface, each VTN can be allocated with a subset of 330 link resources (e.g. bandwidth). A subset of link resources may be 331 dedicated to a VTN, or may be shared by a group of VTNs. Each subset 332 of link resource can be represented as a virtual layer-2 member link 333 under the Layer-3 interface, and the Layer-3 interface is considered 334 as a virtual Layer-2 bundle. The Layer-3 interface may also be a 335 physical Layer 2 link bundle, in this case a subset of link resources 336 allocated to a VTN may be provided by one of the physical Layer-2 337 member links. 339 [RFC8668] describes the IS-IS extensions to advertise the link 340 attributes of the Layer 2 member links which comprise a Layer 3 341 interface. Such mechanism can be extended to advertise the 342 attributes of each physical or virtual member links, and its 343 associated VTNs. 345 A new flag "E" (Exclusive) is defined in the flag field of the Parent 346 L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV (25). 348 0 1 2 3 4 5 6 7 349 +-+-+-+-+-+-+-+-+ 350 |P|E| | 351 +-+-+-+-+-+-+-+-+ 353 E flag: When the E flag is set, it indicates each member link under 354 the Parent L3 link are used exclusively for one or a specific group 355 of VTNs, and load sharing among the member links is not allowed. 356 When the E flag is clear, it indicates load balancing and sharing 357 among the member links are allowed. 359 A new VTN-IDs sub-TLV is carried under the L2 Bundle Attribute 360 Descriptors to describe the mapping relationship between the VTNs and 361 the virtual or physical member links. As one or more VTNs may use 362 the same set of link resource on a specific network segment, these 363 VTN IDs will be advertised under the same virtual or physical member 364 link. 366 The format of the VTN-IDs Sub-TLV is as below: 368 0 1 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Type | Length | Flags | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | VTN ID #1 | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 ~ ... ~ 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | VTN ID #n | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Where: 382 * Type: TBD 384 * Length: The length of the value field of the sub-TLV. It is 385 variable dependent on the number of VTN IDs included. 387 * Flags: 16 bit flags. All the bits are reserved for future use, 388 which SHOULD be set to 0 on transmission and MUST be ignored on 389 receipt. 391 * VTN IDs: One or more 32-bit identifier to identify the VTNs this 392 member link belongs to. 394 Each physical or virtual member link MAY be associated with a 395 different group of VTNs. Thus each L2 Bundle Attribute Descriptor 396 may carry the link local identifier and attributes of only one Layer 397 2 member link. Multiple L2 Bundle Attribute Descriptors will be used 398 to carry the attributes and the associated VTN-IDs of all the Layer 2 399 member links. 401 The TE attributes of each virtual or physical member link, such as 402 the bandwidth attributes and the SR SIDs, can be advertised using the 403 mechanism as defined in [RFC8668]. 405 4.2. Option 2: Per-VTN Link TE Attributes 407 A Layer-3 interface can participate in multiple VTNs, each of which 408 is allocated with a subset of the forwarding resources of the 409 interface. For each VTN, the associated resources can be described 410 using per-VTN TE attributes. A new VTN-specific TE attribute sub-TLV 411 is defined to advertise the link attributes associated with a VTN. 412 This sub-TLV MAY be advertised as a sub-TLV of the following TLVs: 414 TLV-22 (Extended IS reachability) [RFC5305] 416 TLV-23 (IS Neighbor Attribute) [RFC5311] 418 TLV-141 (Inter-AS Reachability Information) [RFC5316] 420 TLV-222 (MT ISN) [RFC5120] 422 TLV-223 (MT IS Neighbor Attribute) [RFC5311] 424 The format of the sub-TLV is shown as below: 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Type | Length | Flags | Reserved | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | VTN ID Sub-sub-TLV | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 ~ Other Sub-sub-TLVs ~ 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Where: 438 * Type: TBD 440 * Length: The length of the value field of the sub-TLV. It is 441 variable dependent on the length of the Sub-sub-TLVs field. 443 * Flags: 8-bit flags. All the 8 bits are reserved for future use, 444 which SHOULD be set to 0 on transmission and MUST be ignored on 445 receipt. 447 * Reserved: 8-bit field reserved for future use, SHOULD be set to 0 448 on transmission and MUST be ignored on receipt. 450 * VTN ID Sub-sub-TLV: contains one or more VTN IDs which is 451 associated with the same group of TE attributes. 453 * Other Sub-sub-TLVs: the TLVs which carry the TE attributes 454 associated with the VTNs. 456 The format of the VTN ID sub-sub-TLV is shown as below: 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Type | Length | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | VTN ID #1 | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 ~ ... ~ 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Where: 470 * Type: TBD 472 * Length: The length of the value field of the sub-sub-TLV. It is 473 the number of the VTN IDs in the TLV multiplied by 4. 475 * VTN ID: A global significant 32-bit identifier which is used to 476 identify a VTN. 478 One sub-sub-TLV "VTN bandwidth sub-sub-TLV" is defined in this 479 document. Its format is shown as below: 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Type | Length | Flags | Reserved | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Bandwidth | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 Where: 491 * Type: TBD 493 * Length: The length of the value field of the sub-sub-TLV. It is 494 set to 6. 496 * Flags: 8-bit flags. All the 8 bits are reserved for future use, 497 which SHOULD be set to 0 on transmission and MUST be ignored on 498 receipt. 500 * Reserved: 8-bit field reserved for future use, SHOULD be set to 0 501 on transmission and MUST be ignored on receipt. 503 * Bandwidth: The bandwidth allocated to the VTN, encoded in 32 bits 504 in IEEE floating point format. 506 The VTN-specific Bandwidth sub-sub-TLV is optional. This sub-sub-TLV 507 SHOULD appear once at most in each VTN-specific TE attribute sub-TLV. 509 5. Advertisement of VTN specific Data Plane Identifiers 511 In order to steer packets to the VTN-specific paths which are 512 computed taking the topology and network resources of the VTN as the 513 constraints, some fields in the data packet needs to be used to infer 514 or identify the VTN the packet belongs to. As multiple VTNs may 515 share the same topology or Flex-Algo, the topology/Flex-Algo specific 516 SR SIDs or Locators cannot be used to distinguish the packets which 517 belong to different VTNs. Some additional data plane identifiers 518 would be needed to identify the VTN a packet belongs to. 520 This section describes the mechanisms to advertise the VTN 521 identifiers in different data plane encapsulations. 523 5.1. Advertisement of VTN-specific SR-MPLS SIDs 525 With SR-MPLS data plane, the VTN identification information can be 526 implicitly carried in the VTN-specific SIDs. Each node SHOULD 527 allocate a unique Prefix-SID for each VTN it participates in. On a 528 Layer-3 interface, if each Layer 2 member link is associated with 529 only one VTN, the adj-SIDs of the L2 member links could also identify 530 the VTNs. If a member link is associated with multiple VTNs, VTN- 531 specific adj-SIDs MAY need to be allocated to help the VTN-specific 532 local protection. 534 A new VTN-specific prefix-SID sub-TLV is defined to advertise the 535 prefix-SID and its associated VTN. This sub-TLV MAY be advertised as 536 a sub-TLV of the following TLVs: 538 TLV-135 (Extended IPv4 Reachability) defined in [RFC5305]. 540 TLV-235 (MT IP Reachability) defined in [RFC5120]. 542 TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. 544 TLV-237 (MT IPv6 IP Reachability) defined in [RFC5120]. 546 The format of the sub-TLV is shown as below: 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Type | Length | Flags | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | VTN ID | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | SID/Index/Label(Variable) | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 Where: 560 * Type: TBD 562 * Length: The length of the value field of the sub-TLV. It is 563 variable dependent on the length of the SID/Index/Label field. 565 * Flags: 16-bit flags. The high-order 8 bits are the same as in the 566 Prefix-SID sub-TLV defined in [RFC8667]. The lower-order 8 bits 567 are reserved for future use, which SHOULD be set to 0 on 568 transmission and MUST be ignored on receipt. 570 * VTN ID: A 32-bit identifier to identify the VTN this prefix-SID 571 associates with. 573 * SID/Index/Label: The same as defined in [RFC8667]. 575 One or more of VTN-specific Prefix-SID sub-TLVs MAY be carried in the 576 Multi-topology IP Reachability TLVs (TLV 235 or TLV 237), the MT-ID 577 of the TLV SHOULD be the same as the MT-ID in the definition of these 578 VTNs. 580 A new VTN-specific Adj-SID sub-TLV is defined to advertise the adj- 581 SID and its associated VTN. This sub-TLV may be advertised as a sub- 582 TLV of the following TLVs: 584 TLV-22 (Extended IS reachability) [RFC5305] 586 TLV-23 (IS Neighbor Attribute) [RFC5311] 588 TLV-25 (L2 Bundle Member Attributes) [RFC8668] 590 TLV-141 (Inter-AS Reachability Information) [RFC5316] 592 TLV-222 (MT ISN) [RFC5120] 594 TLV-223 (MT IS Neighbor Attribute) [RFC5311] 596 The format of the sub-TLV is shown as below: 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Type | Length | Flags | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | VTN ID | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | SID/Index/Label(Variable) | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Where: 610 * Type: TBD 612 * Length: The length of the value field of the sub-TLV. It is 613 variable dependent on the length of the SID/Index/Label field. 615 * Flags: 16-bit flags. The high-order 8 bits are the same as in the 616 Adj-SID sub-TLV defined in [RFC8667]. The lower-order 8 bits are 617 reserved for future use, which SHOULD be set to 0 on transmission 618 and MUST be ignored on receipt. 620 * VTN ID: A 32-bit global identifier to identify the VTN this Adj- 621 SID associates with. 623 * SID/Index/Label: The same as defined in [RFC8667]. 625 One or more VTN-specific Adj-SID sub-TLV MAY be carried in the Multi- 626 topology ISN or Multi-topology IS Attribute TLVs (TLV 222 or TLV 627 223), the MT-ID of the TLV SHOULD be the same as the MT-ID in the 628 definition of these VTNs. 630 5.2. Advertisement of VTN-specific SRv6 Locators and SIDs 632 5.2.1. VTN-specific SRv6 Locators and End SIDs 634 With SRv6 data plane, the VTN identification information can be 635 implicitly or explicitly carried in the SRv6 Locator of the 636 corresponding VTN, this is to ensure that all network nodes 637 (including both the end nodes and the transit nodes) can identify the 638 VTN to which a packet belongs to. Network nodes SHOULD allocate VTN- 639 specific Locators for each VTN it participates in. The VTN-specific 640 Locators are used as the covering prefix of VTN-specific SRv6 End 641 SIDs, End.X SIDs and other types of SIDs. 643 In one possible approach, each VTN-specific Locator is advertised in 644 a separate TLV called "VTN specific SRv6 Locator TLV". Its format is 645 shown as below: 647 0 1 2 3 648 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 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Type | Length |R|R|R|R| MT ID | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Locator Entries . . . | 654 Where: 656 * Type: TBD 658 * The semantics of the Length field, the R bits and the MT ID field 659 are the same as those defined in 660 [I-D.ietf-lsr-isis-srv6-extensions]. 662 Followed by one or more locator entries of the form: 664 0 1 2 3 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Metric | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Flags | Algorithm | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | VTN ID | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Loc Size | 674 +-+-+-+-+-+-+-+-+ 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 // Locator (continued, variable) // 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Sub-TLV-len | Sub-TLVs (variable) . . . | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 Where: 684 * VTN ID: A 32-bit global identifier to identify the VTN this 685 Locator associates with. 687 * All the other fields are the same as those defined in 688 [I-D.ietf-lsr-isis-srv6-extensions]. 690 The VTN-specific SRv6 End SIDs are carried in the VTN-specific SRv6 691 Locator TLV, and inherits the topology, algorithm and VTN from the 692 parent VTN-specific Locator. 694 In another possible approach, when a group of VTNs share the same 695 topology/algorithm, the topology/algorithm specific Locator is the 696 covering prefix of a group of VTN-specific Locators. Then the 697 advertisement of VTN-specific locators can be optimized to reduce the 698 amount of Locator TLVs advertised in the control plane. 700 A new VTN locator-block sub-TLV under the SRv6 Locator TLV is defined 701 to advertise a set of sub-blocks which follows the topology/algorithm 702 specific Locator. Each VTN locator-block value is assigned to one of 703 the VTNs which share the same topology/algorithm. 705 0 1 2 3 706 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 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Type | Length | Number of VTNs| Block Length | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | VTN ID #1 | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 ~ Locator Block Value ~ 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 ~ ... ~ 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | VTN ID #n | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 ~ Locator Block Value ~ 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 Where: 723 * Type: TBD 725 * Length: The length of the value field of the sub-TLV. It is 726 variable dependent on the number of VTNs and the Block Length. 728 * Number of VTNs: The number of VTNs which share the same topology/ 729 algorithm specific Locator as the covering prefix. 731 * Block Length: The length of the VTN locator-block which follows 732 the length of the topology/algorithm specific Locator. 734 * VTN ID: A 32-bit global identifier to identify the VTN the 735 locator-block is associates with. 737 * Block Value: The value of the VTN locator-block for each VTN. 739 With the VTN locator-block sub-TLV, the VTN-specific Locator can be 740 obtained by concatenating the topology/algorithm specific locator and 741 the locator-block value advertised for the VTN. 743 The VTN-specific SRv6 End SIDs inherit the topology, algorithm and 744 the VTN from the parent VTN-specific Locator. 746 5.2.2. VTN-specific SRv6 End.X SIDs 748 The SRv6 End.X SIDs are advertised as sub-TLVs of TLV 22, 23, 25, 749 141, 222, and 223. In order to distinguish the End.X SIDs which 750 belong to different VTNs, a new "VTN ID sub-sub-TLV" is introduced 751 under the SRv6 End.X SID sub-TLV and SRv6 LAN End.X SID sub-TLV 752 defined in [I-D.ietf-lsr-isis-srv6-extensions]. Its format is shown 753 as below: 755 0 1 2 3 756 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 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Type | Length | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | VTN ID | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 Where: 765 * Type: TBD. 767 * Length: the length of the Value field of the TLV. It is set to 4. 769 * VTN ID: A 32-bit global identifier to identify the VTN this End.X 770 SID associates with. 772 5.3. Advertisement of Dedicated Data Plane VTN IDs 774 As the number of VTNs increases, with the mechanism described in 775 [I-D.ietf-spring-sr-for-enhanced-vpn], the number of SR SIDs and SRv6 776 Locators allocated for different VTNs would also increase. In 777 network scenarios where the number of SIDs or Locators becomes a 778 concern, some data plane optimization may be needed to reduce the 779 amount of SR SIDs and Locators allocated. As described in 780 [I-D.dong-teas-nrp-scalability], one approach is to decouple the data 781 plane identifiers used for topology based forwarding and the 782 identifiers used for the VTN-specific processing. Thus a dedicated 783 data plane VTN-ID could be encapsulated in the packet. One possible 784 encapsulation of VTN-ID in IPv6 data plane is proposed in 785 [I-D.dong-6man-enhanced-vpn-vtn-id]. One possible encapsulation of 786 VTN-ID in MPLS data plane is proposed in 788 [I-D.li-mpls-enhanced-vpn-vtn-id]. 790 In that case, the VTN-ID encapsulated in data plane can have the same 791 value as the VTN-ID in control plane, so that the overhead of 792 advertising the mapping between the control plane VTN-IDs and the 793 corresponding data plane identifiers could be saved. 795 6. Security Considerations 797 This document introduces no additional security vulnerabilities to 798 IS-IS. 800 The mechanism proposed in this document is subject to the same 801 vulnerabilities as any other protocol that relies on IGPs. 803 7. IANA Considerations 805 IANA is requested to assign a new code point in the "sub-TLVs for TLV 806 242 registry". 808 Type: TBD1 809 Description: Virtual Transport Network Definition 811 IANA is requested to assign three new code points in the "sub-TLVs 812 for TLVs 22, 23, 25, 141, 222, and 223 registry". 814 Type: TBD2 815 Description: Virtual Transport Network Identifiers 817 Type: TBD3 818 Description: VTN-specific TE attribute sub-TLV 820 Type: TBD4 821 Description: VTN-specific Adj-SID 823 IANA is requested to assign two new code points in the "Sub-TLVs for 824 TLVs 27, 135, 235, 236 and 237 registry". 826 Type: TBD5 827 Description: VTN-specific Prefix-SID 829 Type: TBD6 830 Description: VTN locator-block 832 IANA is requested to assign a new code point in the "IS-IS TLV 833 Codepoints registry". 835 Type: TBD7 836 Description: VTN-specific SRv6 Locator TLV 838 IANA is requested to assign a new code point in the "sub-sub-TLVs for 839 SRv6 End SID and SRv6 End.X SID registry". 841 Type: TBD8 842 Description: VTN ID Sub-sub-TLV 844 8. Contributors 846 Hongjie Yang 847 Email: hongjie.yang@huawei.com 849 9. Acknowledgments 851 The authors would like to thank Mach Chen, Dean Cheng and Guoqi Xu 852 for their review and discussion of this document. 854 10. References 856 10.1. Normative References 858 [I-D.ietf-lsr-flex-algo] 859 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 860 A. Gulko, "IGP Flexible Algorithm", Work in Progress, 861 Internet-Draft, draft-ietf-lsr-flex-algo-18, 25 October 862 2021, . 865 [I-D.ietf-lsr-isis-srv6-extensions] 866 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 867 Z. Hu, "IS-IS Extensions to Support Segment Routing over 868 IPv6 Dataplane", Work in Progress, Internet-Draft, draft- 869 ietf-lsr-isis-srv6-extensions-18, 20 October 2021, 870 . 873 [I-D.ietf-spring-resource-aware-segments] 874 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 875 Z., and F. Clad, "Introducing Resource Awareness to SR 876 Segments", Work in Progress, Internet-Draft, draft-ietf- 877 spring-resource-aware-segments-03, 12 July 2021, 878 . 881 [I-D.ietf-spring-sr-for-enhanced-vpn] 882 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 883 Z., and F. Clad, "Segment Routing based Virtual Transport 884 Network (VTN) for Enhanced VPN", Work in Progress, 885 Internet-Draft, draft-ietf-spring-sr-for-enhanced-vpn-01, 886 12 July 2021, . 889 [I-D.ietf-teas-enhanced-vpn] 890 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 891 Framework for Enhanced Virtual Private Network (VPN+) 892 Services", Work in Progress, Internet-Draft, draft-ietf- 893 teas-enhanced-vpn-09, 25 October 2021, 894 . 897 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 898 Requirement Levels", BCP 14, RFC 2119, 899 DOI 10.17487/RFC2119, March 1997, 900 . 902 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 903 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 904 RFC 4915, DOI 10.17487/RFC4915, June 2007, 905 . 907 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 908 Topology (MT) Routing in Intermediate System to 909 Intermediate Systems (IS-ISs)", RFC 5120, 910 DOI 10.17487/RFC5120, February 2008, 911 . 913 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 914 for Advertising Router Information", RFC 7981, 915 DOI 10.17487/RFC7981, October 2016, 916 . 918 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 919 Decraene, B., Litkowski, S., and R. Shakir, "Segment 920 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 921 July 2018, . 923 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 924 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 925 Extensions for Segment Routing", RFC 8667, 926 DOI 10.17487/RFC8667, December 2019, 927 . 929 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 930 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 931 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 932 December 2019, . 934 10.2. Informative References 936 [I-D.dong-6man-enhanced-vpn-vtn-id] 937 Dong, J., Li, Z., Xie, C., Ma, C., and G. Mishra, 938 "Carrying Virtual Transport Network (VTN) Identifier in 939 IPv6 Extension Header", Work in Progress, Internet-Draft, 940 draft-dong-6man-enhanced-vpn-vtn-id-06, 24 October 2021, 941 . 944 [I-D.dong-teas-nrp-scalability] 945 Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J. N., 946 Mishra, G., and F. Qin, "Scalability Considerations for 947 Network Resource Partition", Work in Progress, Internet- 948 Draft, draft-dong-teas-nrp-scalability-00, 17 December 949 2021, . 952 [I-D.li-mpls-enhanced-vpn-vtn-id] 953 Li, Z. and J. Dong, "Carrying Virtual Transport Network 954 Identifier in MPLS Packet", Work in Progress, Internet- 955 Draft, draft-li-mpls-enhanced-vpn-vtn-id-01, 14 April 956 2021, . 959 Authors' Addresses 961 Jie Dong 962 Huawei Technologies 964 Email: jie.dong@huawei.com 966 Zhibo Hu 967 Huawei Technologies 969 Email: huzhibo@huawei.com 971 Zhenbin Li 972 Huawei Technologies 974 Email: lizhenbin@huawei.com 975 Xiongyan Tang 976 China Unicom 978 Email: tangxy@chinaunicom.cn 980 Ran Pang 981 China Unicom 983 Email: pangran@chinaunicom.cn 985 Lee JooHeon 986 LG U+ 988 Email: playgame@lguplus.co.kr 990 Stewart Bryant 991 Futurewei Technologies 993 Email: stewart.bryant@gmail.com