idnits 2.17.00 (12 Aug 2021) /tmp/idnits21266/draft-lee-teas-actn-vpn-poi-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 26 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 19, 2018) is 1303 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 134, but not defined == Missing Reference: 'RFC8174' is mentioned on line 134, but not defined == Missing Reference: 'RFC6074' is mentioned on line 569, but not defined == Missing Reference: 'RFC4761' is mentioned on line 573, but not defined == Missing Reference: 'RFC6624' is mentioned on line 573, but not defined == Missing Reference: 'RFC7436' is mentioned on line 576, but not defined == Missing Reference: 'RFC7432' is mentioned on line 581, but not defined == Missing Reference: 'RFC7209' is mentioned on line 579, but not defined == Missing Reference: 'RFC8214' is mentioned on line 581, but not defined == Unused Reference: 'DHODY' is defined on line 761, but no explicit reference was found in the text == Unused Reference: 'ACTN-VN' is defined on line 771, but no explicit reference was found in the text == Unused Reference: 'TE-Topo' is defined on line 778, but no explicit reference was found in the text == Unused Reference: 'RFC8309' is defined on line 782, but no explicit reference was found in the text == Unused Reference: 'L3SM' is defined on line 785, but no explicit reference was found in the text == Unused Reference: 'L2SM' is defined on line 788, but no explicit reference was found in the text == Outdated reference: draft-ietf-teas-yang-te-topo has been published as RFC 8795 == Outdated reference: draft-ietf-l2sm-l2vpn-service-model has been published as RFC 8466 Summary: 1 error (**), 0 flaws (~~), 19 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group Y. Lee 2 Internet Draft Q. Wu 3 Intended status: Informational I. Busi 4 Expires: April 20, 2019 Huawei 6 D. Cecarreli 7 Ericsson 9 J. Tantsura 10 Apstra 12 October 19, 2018 14 Applicability of Abstraction and Control of Traffic Engineered Networks 15 (ACTN) to VPN with the Integration of Packet and Optical Networks 17 draft-lee-teas-actn-vpn-poi-00 18 Abstract 20 This document outlines the applicability of Abstraction and 21 Control of Traffic Engineered Networks (ACTN) to VPN with the 22 integration of Packet and Optical Networks (POI). It also 23 identifies a number of scenarios where the integration of packet 24 and optical networks is necessary to support VPN service 25 requirements. The role of optical underlay tunnels in the POI is 26 to support certain applications that require a hard isolation with 27 strict deterministic latency and guaranteed constant bandwidth. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with 32 the provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other 41 documents at any time. It is inappropriate to use Internet-Drafts 42 as reference material or to cite them other than as "work in 43 progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on April 20, 2019. 52 Copyright Notice 54 Copyright (c) 2018 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with 62 respect to this document. Code Components extracted from this 63 document must include Simplified BSD License text as described in 64 Section 4.e of the Trust Legal Provisions and are provided without 65 warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction.................................................3 70 1.1. Requirements Language.....................................3 71 2. Background and Scope.........................................4 72 3. POI with L2/L3VPN Service Under Single Network Operator Control 73 ................................................................5 74 3.1. POI with single packet and single optical domain..........5 75 3.2. POI with multiple packet domains and single optical domain8 76 3.3. POI with multiple packet domains and multiple optical 77 domains.......................................................10 78 3.4. Transport of Tunnel and VPN information..................12 79 3.5. Virtual Switching Instance (VSI) Provisioning for L2VPN..13 80 3.6. Inter-domain Links Update................................13 81 3.7. End-to-end Tunnel Management.............................13 82 4. POI with VN Recursion Under Multiple Network Operators Control 83 ...............................................................14 84 4.1. Service Request Process between Multiple Operators.......15 85 4.2. Service/Network Orchestration of Operator 2..............16 86 5. Security Considerations.....................................16 87 6. IANA Considerations.........................................17 88 7. References..................................................17 89 7.1. Normative References.....................................17 90 7.2. Informative References...................................17 91 8. Contributors................................................18 92 Authors' Addresses.............................................18 94 1. Introduction 96 Abstraction and Control of Traffic Engineered Networks (ACTN) 97 describes a set of management and control functions used to 98 operate one or more TE networks to construct virtual networks that 99 can be represented to customers and that are built from 100 abstractions of the underlying TE networks so that, for example, a 101 link in the customer's network is constructed from a path or 102 collection of paths in the underlying networks [RFC8453]. 104 This document outlines the applicability of ACTN to VPN with the 105 integration of packet and optical networks which is known as the 106 Packet and Optical Integration (POI). 108 It also identifies a number of scenarios where the integration of 109 packet and optical networks is necessary to support VPN service 110 requirements. The role of optical underlay tunnels in the POI is 111 to support certain applications that require a hard isolation with 112 strict deterministic latency and guaranteed constant bandwidth. 114 Note that there may be other transport technologies that can 115 support the aforementioned service requirements such as TSN or 116 Detnet to name a few. In this particular document, we are focusing 117 on the currently available network settings where packet networks 118 are a client layer to optical transport networks as a server 119 layer. The principle discussed in this document can be applied to 120 other transport technologies when they are available. 122 As ACTN [RFC8453] introduces the role of controllers that 123 facilitate network operations, the scope of this document is how 124 controllers can facilitate L2/3VPN service provisioning in the 125 packet and optical transport networks. 127 1.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 130 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 131 "MAY", and "OPTIONAL" in this document are to be interpreted as 132 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they 133 appear in all capitals, as shown here. 135 2. Background and Scope 137 One of the important functions the MDSC performs is to identify 138 which TE Tunnels should carry the L3VPN traffic and to relay this 139 information to the domain-level controllers to ensure proper 140 Virtual routing and forwarding (VRF) table be populated according 141 to the TE binding requirement for the L3VPN. This function is 142 referred to as TE & service mapping function. The YANG model to 143 provide TE & service mapping function is provided in [TSM]. The 144 role of the TE-service Mapping model [TSM] is to expose the 145 mapping relationship between service models and TE models so that 146 VN/VPN service instantiations provided by the underlying TE 147 networks can be viewed outside of the MDSC. 149 The TE-Service Mapping model also provides service-TE binding 150 information for each service instance so that proper TE tunnel 151 should be created. 153 The TE binding requirement types defined in [TSM] are: 155 a) New VN/Tunnel Binding - A customer could request a VPN 156 service based on VN/Tunnels that are not shared with other 157 existing or future services. This might be to meet VPN 158 isolation requirements. 160 Under this mode, the following sub-categories can be 161 supported: 163 i. Hard Isolation with deterministic characteristics: A 164 customer could request a VPN service using a set of TE 165 Tunnels with deterministic characteristics requirements 166 (e.g., no latency variation) and where that set of TE 167 Tunnels must not be shared with other VPN services and 168 must not compete for bandwidth or other network 169 resources with other TE Tunnels. 171 ii. Hard Isolation: This is similar to the above case but 172 without the deterministic characteristics requirements. 174 iii. Soft Isolation: The customer requests a VPN service 175 using a set of TE tunnels which can be shared with other 176 VPN services. 178 b) VN/Tunnel Sharing - A customer could request a VPN service 179 where new tunnels (or a VN) do not need to be created for 180 each VPN and can be shared across multiple VPNs. 182 c) VN/Tunnel Modify - This mode allows the modification of the 183 properties of the existing VN/tunnel (e.g., bandwidth). 185 This document addresses cases a)-i (hard isolation with 186 deterministic latency) and a)-ii (hard isolation with non- 187 deterministic latency). Both cases warrant consideration of 188 optical undelay bypass tunnels to meet the service requirement. 190 The optical bypass tunnel could be setup via RSVP-TE signaling and 191 thus tunnel label allocation could be done during signaling. It is 192 also possible that PNC and MDSC coordinates to exchange the TE 193 tunnel label information to setup this optical bypass tunnel. This 194 document focuses on the latter case. 196 The multi-hop e-BGP session between ingress and egress for multi- 197 domain case would be setup to exchange VPN routes. The rest of the 198 forwarding action is as per the usual BGP L3VPN handling including 199 the use of TE tunnel. 201 3. POI with L2/L3VPN Service Under Single Network Operator Control 203 This section provides a set of specific deployment scenarios for 204 POI under single network operator control. Specifically, the 205 following deployment scenarios are discussed in this section: 207 - One optical transport domain overarched by one packet domain 208 (see Section 3.1); 209 - One optical transport domain overarched by multiple packet 210 domains (see Section 3.2); 211 - multiple optical transport domains overarched by multiple packet 212 domains (see Section 3.3). 214 All scenarios are taking place in the context of an upper layer 215 service configuration (e.g., L3VPN) in the packet and optical 216 transport network. 218 Since this document only addresses the procedure for creating 219 optical underlay bypass tunnels, it does not affect MP-BGP MPLS 220 operations for inter-AS scenarios as specified in [RFC4364]. 222 3.1. POI with single packet and single optical domain 224 This section provides a specific deployment scenario for POI. 225 Specifically, it provides a deployment scenario in which 226 hierarchical controllers (an MDSC and two PNCs, one for packet and 227 one for optical) facilitate optical bypass tunnel across the 228 packet domain and the optical domain. 230 Figure 1 shows this scenario. 232 +----------+ 233 | MDSC | 234 +----------+ 235 | 236 --------- 237 | | 238 +--------+ +--------+ 239 | P-PNC | | O-PNC | 240 +--------+ +--------+ 241 | | 242 | | 243 +----------------------+ 244 CE / PE PE \ CE 245 o--/---o o---\---o 246 \ : : / 247 \ : AS Domain : / 248 +-:------------------:-+ 249 : | : 250 : | : 251 +-:------------------:-+ 252 / : : \ 253 / o..................o \ 254 \ Optical Domain / 255 \ / 256 +----------------------+ 258 Figure 1. One Packet Domain and One Optical Domain 260 The following control sequence describes the scenario depicted in 261 Figure 1. 263 a) The MDSC translates the service instance and its requirement 264 (hard isolation with deterministic latency). 265 b) The MDSC computes the path if there is any feasible path to 266 meet the requirement based on the abstracted topology at 267 hand. Note that there would not be any tunnel in the packet 268 domain to meet this requirement (hard isolation with 269 deterministic latency). 270 c) The MDSC finds a feasible path in the optical domain. 271 d) The MDSC asks the optical PNC to create a tunnel for this VPN 272 instance whose endpoints are the ingress PE and the egress PE 273 of the packet domain, respectively. The MDSC and Optical PNC 274 need to maintain an instance ID for this VPN instance. 275 e) The MDSC asks the Packet PNC to bind a TE-tunnel label (to be 276 allocated by the egress PE to identify the underlay optical 277 tunnel) with the VPN ID and the Ingress and Egress interfaces 278 of the underlay optical tunnel. 279 f) The PNC in turn asks the Egress PE to allocate a TE-tunnel 280 label. The Egress PE allocates a TE-tunnel label, populates 281 the VRF for this VPN instance, and updates the Packet PNC 282 with the allocated TE-tunnel label. Please refer to the note 283 below on the details of this procedure in regard to VPN 284 binding. 286 Note: There are two cases for binding network instance with 287 the TE tunnel label: 289 1. VRF instance does not exist. 290 2. VRF instance has already been created. 292 For case 1, the Egress PE needs to bind the TE-tunnel label 293 and the VPN information (e.g., VPN instance name, VPN label, 294 RD, RT, Destination IP address, etc.) and inform this binding 295 information to the packet PNC. 297 g) The packet PNC informs the MDSC the allocated TE-tunnel label 298 for the VPN instance. 299 h) The MDSC informs the optical PNC to bind the TE-tunnel label 300 with the VPN instance, which has been created previously in 301 step d). 302 i) The optical PNC informs this binding information (i.e., 303 ingress/egress interfaces from packet domain and the TE- 304 tunnel label) to the optical ingress switch. 305 j) The packet PNC informs the ingress PE to use the TE-label for 306 this VPN instance. The Ingress PE populates the VRF for the 307 VPN with the TE-label. (Note that the TE-label would need to 308 be PUSHed over the VPN traffic). 309 k) When the packet arrives at the ingress PE, it recognizes the 310 VPN instance and PUSHes the VPN label and the TE-tunnel label 311 and forward the traffic to optical ingress switch. 312 l) The optical ingress switch recognizes the TE-tunnel label and 313 encapsulate the whole data packet including TE-tunnel label 314 into the OTN payload. 315 m) The optical egress switch POPs the ODU label and forwards the 316 data packet to the packet egress PE. 317 n) The packet egress PE POPs the TE-tunnel label and forwards 318 the VPN packets to the destination CE. 320 Note: in steps k) - l), the assumption made was that the packet 321 ingress PE is not OTN-capable router. If the packet ingress PE 322 support channelized OTN interfaces, the data plane behavior in 323 steps k) and l) would change as the following: 325 k') When the packets arrives at the ingress PE, it recognizes 326 the VPN instance and PUSHes the VPN label and the TE-tunnel 327 label and the ODU label and forward the traffic to optical 328 ingress switch. 330 l') The optical ingress switch recognizes the incoming ODU 331 label and swap it to outgoing ODU label. 333 3.2. POI with multiple packet domains and single optical domain 335 This section provides a specific deployment scenario for POI. 336 Specifically, it provides a deployment scenario in which 337 hierarchical controllers (an MDSC and two packet PNCs and one 338 optical PNC) facilitate optical bypass tunnel across the two 339 packet domains and the optical domain. 341 Figure 2 shows this scenario. 343 +----------+ 344 | MDSC | 345 +----------+ 346 | 347 -------------------|------------------- 348 | | | 349 +--------+ +--------+ +--------+ 350 | P-PNC 1| | O-PNC | | P-PNC 2| 351 +--------+ +--------+ +--------+ 352 | | | 353 | | | 354 +----------------------+ | +----------------------+ 355 CE / PE ASBR \ | / ASBR PE \ CE 356 o--/---o o---\-----|-----/---o o----\--o 357 \ : / | \ : / 358 \ : AS Domain 1 / | \ AS Domain 2 : / 359 +-:--------------------+ | +-------------------:--+ 360 : | : 361 : | : 362 +-:--------------------------------------------------------:--+ 363 / : : \ 364 / o........................................................o \ 365 \ Optical Domain / 366 \ / 367 +-------------------------------------------------------------+ 369 Figure 2. Two Packet Domains and One Optical Domain 371 The control sequence depicted in Figure 2 is same as the control 372 sequence a)-d) in Section 3.1 with the following differences: 374 e) The MDSC asks the Packet PNC 2 to bind a TE-tunnel label (to 375 be allocated by the egress PE to identify the underlay 376 optical tunnel) with the VPN ID and the Ingress and Egress 377 interfaces of the underlay optical tunnel. 378 f) The packet PNC 2 in turn asks the Egress PE to allocate a TE- 379 tunnel label. The Egress PE allocates a TE-tunnel label, 380 populates the VRF for this VPN instance, and updates the 381 packet PNC 2 with the allocated TE-tunnel label. Please refer 382 to the note below on the details of this procedure in regard 383 to VPN binding. 385 Note: There are two cases for binding network instance with 386 the TE tunnel label: 388 1. VRF instance does not exist. 389 2. VRF instance has already been created. 391 For case 1, the Egress PE needs to bind the TE-tunnel label 392 and the VPN information (e.g., VPN instance name, VPN label, 393 RD, RT, Destination IP address, etc.) and inform this binding 394 information to the packet PNC 2. 396 g) The packet PNC 2 informs the MDSC the allocated TE-tunnel 397 label for the VPN instance. 398 h) The MDSC informs the packet PNC 1 the allocated TE-tunnel 399 label for the VPN instance. 400 i) The MDSC informs the optical PNC to bind the TE-tunnel label 401 with the VPN instance, which has been created previously in 402 step d). 403 j) The optical PNC informs this binding information (i.e., 404 ingress/egress interfaces from packet domain and the TE- 405 tunnel label) to the optical ingress switch. 406 k) The packet PNC 1 informs the ingress PE in Domain 1 to use 407 the TE-tunnel label for this VPN instance. The Ingress PE in 408 Domain 2 populates the VRF for the VPN and bind with the TE- 409 tunnel label. (Note that the TE-tunnel label would need to be 410 PUSHed over the VPN traffic). 411 l) When the packets arrives at the ingress PE in Domain 1, it 412 recognizes the VPN instance and PUSHes the VPN label and the 413 TE-tunnel label and forward the traffic to optical ingress 414 switch. 416 m) The optical ingress switch recognizes the TE-tunnel label and 417 encapsulate the whole data packet including TE-tunnel label 418 into the OTN payload. 419 n) The optical egress switch POPs the ODU label and forwards the 420 data packet to the packet egress PE. 421 o) The packet egress PE in Domain 2 POPs the TE-tunnel label and 422 forwards the VPN packets to the destination CE. 424 Note: in steps l) - m), the assumption made was that the packet 425 ingress PE is not OTN-capable router. If the packet ingress PE 426 supports channelized OTN interfaces, the data plane behavior in 427 steps l) and m) would change as the following: 429 l') When the packets arrives at the ingress PE, it recognizes 430 the VPN instance and PUSHes the VPN label and the TE-tunnel 431 label and the ODU label and forward the traffic to optical 432 ingress switch. 434 m') The optical ingress switch recognizes the incoming ODU 435 label and swap it to outgoing ODU label. 437 3.3. POI with multiple packet domains and multiple optical domains 439 This section provides a specific deployment scenario for POI. 440 Specifically, it provides a deployment scenario in which 441 hierarchical controllers (an MDSC and two packet PNCs and two 442 optical PNCs) facilitate optical bypass tunnel across two packet 443 domains and two optical domains. 445 Figure 3 shows this scenario. 447 +----------+ 448 | MDSC | 449 +----------+ 450 | 451 -------------------|------------------- 452 | +--------+ | 453 +--------+ +--------+ 2| +--------+ 454 | P-PNC 1| | O-PNC 1|--+ | P-PNC 2| 455 +--------+ +--------+| +--------+ 456 | | | | 457 | | | | 458 +---------------------- | | +---------------------+ 459 CE / PE ASBR \ | | / ASBR PE \ CE 460 o--/---o o---\-|-------|--/---o o----\--o 461 \ : / | | \ : / 462 \ : AS Domain 1 / | | \ AS Domain 2 : / 463 +-:--------------------+ | | +------------------:--+ 464 : | | : 465 : | | : 466 +-:-------------------------+ +------------------------:--+ 467 / : \ / : \ 468 / o.......................o...\./...o......................o \ 469 \ Optical Domain 1 / \ Optical Domain 2 / 470 \ / \ / 471 +---------------------------+ +---------------------------+ 473 Figure 3. Two Packet Domains and One Optical Domain 475 The control sequence depicted in Figure 3 is same as the control 476 sequence a)-c) in Section 3.1 with the following differences: 478 d) The MDSC asks the optical PNC 1 to create a tunnel for this 479 VPN instance whose endpoints are the ingress PE of the packet 480 domain 1 and the optical inter-domain interface toward 481 optical domain 2; and the optical PNC 2 to create a tunnel 482 for this VPN instance whose endpoints are the optical inter- 483 domain interface from optical domain 1 and the egress PE of 484 the packet domain 2. The MDSC and Optical PNC 1 and PNC 2 485 need to maintain an instance ID for this VPN instance. 486 e) The MDSC asks the Packet PNC 2 to bind a TE-tunnel label with 487 the VPN ID and the Ingress and Egress interfaces of the 488 underlay optical tunnel. 489 f) The packet PNC 2 in turn asks the Egress PE to allocate a TE- 490 tunnel label. The Egress PE allocates a TE-tunnel label, 491 populates the VRF for this VPN instance, and updates the 492 packet PNC 2 with the allocated TE-tunnel label. Please refer 493 to the note below on the details of this procedure in regard 494 to VPN binding. 496 Note: There are two cases for binding network instance with 497 the TE tunnel label: 499 1. VRF instance does not exist. 500 2. VRF instance has already been created. 502 For case 1, the Egress PE needs to bind the TE-tunnel label 503 and the VPN information (e.g., VPN instance name, VPN label, 504 RD, RT, Destination IP address, etc.) and inform this binding 505 information to the packet PNC 2. 507 g) The packet PNC 2 informs the MDSC the allocated TE-tunnel 508 label for the VPN instance. 510 h) The MDSC informs the packet PNC 1 the allocated TE-tunnel 511 label for the VPN instance. 512 i) The MDSC informs the optical PNC 1 and PNC 2 to bind the TE- 513 tunnel label with the instance, which has been created 514 previously in step d). 515 j) The optical PNC 1 informs this binding information (i.e., 516 ingress/egress interfaces from packet domain and the TE- 517 tunnel label) to the optical ingress switch in Domain 1. 518 Likewise, the optical PNC 2 to the optical egress switch in 519 Domain 2. (Note we assume that the optical border switches in 520 Domains 1 and 2 would do the normal OTN switching). 521 k) The packet PNC 1 informs the ingress PE in Domain 1 to use 522 the TE-tunnel label for this VPN instance. The Ingress PE in 523 Domain 2 populates the VRF for the VPN with the TE-label. 524 (Note that the TE-tunnel label would need to be PUSHed over 525 the VPN traffic). 526 l) When the VPN packet arrives at the ingress PE in Domain 1, it 527 recognizes the VPN label and PUSHes the TE-tunnel label and 528 forward the traffic to optical ingress switch in optical 529 domain 1. 530 m) The optical ingress switch in optical domain 1 recognizes the 531 TE-tunnel label and encapsulate the whole data packets 532 including TE-tunnel label into the OTN payload. 533 n) The optical egress switch in optical domain 2 POPs the OTN 534 label and forwards the data packet to the packet egress PE. 535 o) The packet egress PE in Domain 2 POPs the TE-tunnel label and 536 forwards the VPN packet to the destination CE. 538 Note: in steps l) - m), the assumption made was that the packet 539 ingress PE is not OTN-capable router. If the packet ingress PE 540 supports channelized OTN interfaces, the data plane behavior in 541 steps l) and m) would change as the following: 543 l') When the packets arrives at the ingress PE, it recognizes 544 the VPN instance and PUSHes the VPN label and the TE-tunnel 545 label and the ODU label and forward the traffic to optical 546 ingress switch in Domain 1. 548 m') The optical ingress switch in Domain 1 recognizes the 549 incoming ODU label and swap it to outgoing ODU label. 551 3.4. Transport of Tunnel and VPN information 553 The discussions in Section 3 as to the transport mechanism of the 554 TE-tunnel label used for the underlay bypass tunnel with the VPN 555 instance information has the undertone of making use of the 556 controllers. Note that other mechanisms may also be possible and 557 that such mechanisms are not precluded when solutions are sought 558 out. 560 3.5. Virtual Switching Instance (VSI) Provisioning for L2VPN 562 The VSI provisioning for L2VPN is similar to the VPN/VRF provision 563 for L3VPN. L2VPN service types include: 565 . Point-to-point Virtual Private Wire Services (VPWSs) that use 566 LDP-signaled Pseudowires or L2TP-signaled Pseudowires [RFC6074]; 568 . Multipoint Virtual Private LAN Services (VPLSs) that use LDP- 569 signaled Pseudowires or L2TP-signaled Pseudowires [RFC6074]; 571 . Multipoint Virtual Private LAN Services (VPLSs) that use a 572 Border Gateway Protocol (BGP) control plane as described in 573 [RFC4761] and [RFC6624]; 575 . IP-Only LAN-Like Services (IPLSs) that are a functional subset 576 of VPLS services [RFC7436]; 578 . BGP MPLS-based Ethernet VPN Services as described in [RFC7432] 579 and [RFC7209]; 581 . Ethernet VPN VPWS specified in [RFC8214] and [RFC7432]. 583 3.6. Inter-domain Links Update 585 In order to facilitate inter-domain links for the VPN, we assume 586 that the service/network orchestrator would know the inter-domain 587 link status and its resource information (e.g., bandwidth 588 available, protection/restoration policy, etc.) via some 589 mechanisms (which are beyond the scope of this document). We also 590 assume that the inter-domain links are pre-configured prior to 591 service instantiation. 593 3.7. End-to-end Tunnel Management 595 It is foreseen that the MDSC should control and manage end-to-end 596 tunnels for VPNs per VPN policy. 598 As discussed in [ACTN-Telemetry], the MDSC is responsible to 599 collect domain LSP-level performance monitoring data from domain 600 controllers and to derive and report end-to-end tunnel performance 601 monitoring information to the customer. 603 4. POI with VN Recursion Under Multiple Network Operators Control 605 [RFC8453] briefly introduces a case for the VN supplied to a 606 customer may be built using resources from different technology 607 layers operated by different operators. For example, one operator 608 may run a packet TE network and use optical connectivity provided 609 by another operator. 611 Figure 4, extracted from [RFC8453], shows the case where a 612 customer asks for end-to-end connectivity between CE A and CE B, a 613 virtual network. The customer's CNC makes a request to Operator 614 1's MDSC. The MDSC works out which network resources need to be 615 configured and sends instructions to the appropriate PNCs. 616 However, the link between Q and R is a virtual link supplied by 617 Operator 2: Operator 1 is a customer of Operator 2. 619 To support this, Operator 1 has a CNC that communicates with 620 Operator 2's MDSC. Note that Operator 1's CNC in Figure 10 is a 621 functional component that does not dictate implementation: it may 622 be embedded in a PNC. 624 Virtual CE A o===============================o CE B 625 Network 627 ----- CNC wants to create a VN 628 Customer | CNC | between CE A and CE B 629 ----- 630 : 631 *********************************************** CMI 632 : 633 Operator 1 --------------------------- 634 | MDSC | 635 --------------------------- 636 : : : 637 : : : 638 ----- ------------- ----- 639 | PNC | | PNC | | PNC | 640 ----- ------------- ----- 641 : : : : : 642 Higher v v : v v 643 Layer CE A o---P-----Q===========R-----S---o CE B 644 Network | : | 645 | : | 646 | ----- | 647 | | CNC | | CNC wants to create a VN 648 | ----- | between Q and R 649 | : | 650 *********************************************** CMI 651 | : | 652 Operator 2 | ------ | 653 | | MDSC | | 654 | ------ | 655 | : | 656 | ------- | 657 | | PNC | | 658 | ------- | 659 \ : : : / 660 Lower \v v v/ 661 Layer X--Y--Z 662 Network 664 Where 666 --- is a link 667 === is a virtual link 669 Figure 4: VN Recursion with Network Layers 671 The CMI in Figure 4 interfaces Operator 1's CNC with Operator 2's 672 MDSC. The functions to perform and the information carried over 673 the inter-operator CMI are identical to those of the Customer's 674 CNC and Operator 1's MDSC. In other words, the two CMIs depicted 675 in Figure 4 are recursive in nature. 677 From a data plane perspective, the interaction between operator 1 678 and operator 2 is similar to the POI case discussed in section 3.2 679 (See Figure 2) with an exception that the packet domains belong to 680 operator 1 while optical domain to operator 2. 682 The control interface depicted in Figure 4 (i.e., the CNC of 683 operator 1 and the MDSC of operator 2) should behave similarly to 685 4.1. Service Request Process between Multiple Operators 687 As discussed previously, the reclusiveness principle applies 688 seamlessly over the two CMIs. This implies that Operator 1's MDSC 689 needs to pass all customer service requirements transparently to 690 Operator 2's MDSC so that Operator 2 should provision its underlay 691 network tunnels to meet the service requirements of the original 692 customer. The MDSC of Operator 1 should translate/map the original 693 customer's intent and service requirements and pass down to the 694 corresponding PNC(s) which is(are) responsible for interfacing 695 another operator (in this example, Operator 2) that provides 696 transport services for the segment of the customer's VN. The PNC 697 in turn performs as a CNC when interfacing its southbound with 698 Operator 2's MDSC. 700 It is possible that additional recursive relationships may also 701 exist between Operator 2 and other operators. 703 4.2. Service/Network Orchestration of Operator 2 705 Operator 2 that provides transport service for Operator 1 may also 706 need to perform service/network orchestration function just as the 707 case for Operator 1. 709 From a data plane perspective, the interaction between operator 1 710 and operator 2 is similar to the POI case discussed in section 3.2 711 (See Figure 2) with an exception that the packet domains belong to 712 operator 1 while optical domain to operator 2. 714 The control interface depicted in Figure 4 (i.e., the CNC of 715 operator 1 and the MDSC of operator 2) should behave similarly to 716 that of the MDSC and the PNCs discussed in Section 3. 718 5. Security Considerations 720 This document defines key components and interfaces for managed 721 traffic engineered networks. Securing the request and control of 722 resources, confidentially of the information, and availability of 723 function, should all be critical security considerations when 724 deploying and operating ACTN POI platforms. 726 Several distributed ACTN functional components are required, and 727 implementations should consider encrypting data that flows between 728 components, especially when they are implemented at remote nodes, 729 regardless these data flows are on external or internal network 730 interfaces. 732 From a security and reliability perspective, ACTN POI may 733 encounter many risks such as malicious attack and rogue elements 734 attempting to connect to various ACTN POI components. 735 Furthermore, some ACTN POI components represent a single point of 736 failure and threat vector, and must also manage policy conflicts, 737 and eavesdropping of communication between different ACTN POI 738 components. 740 The conclusion is that all protocols used to realize the ACTN POI 741 should have rich security features, and customer, application and 742 network data should be stored in encrypted data stores. Additional 743 security risks may still exist. Therefore, discussion and 744 applicability of specific security functions and protocols will be 745 better described in documents that are use case and environment 746 specific. 748 6. IANA Considerations 750 This document has no actions for IANA. 752 7. References 754 7.1. Normative References 756 [RFC8453] D. Ceccarelli and Y. Lee, "Framework for Abstraction and 757 Control of Transport Networks", RFC 8453, August 2018. 759 7.2. Informative References 761 [DHODY] D. Dhody, et al., "Packet Optical Integration (POI) Use 762 Cases for Abstraction and Control of Transport Networks 763 (ACTN)", draft-dhody-actn-poi-use-case, work in progress. 765 [bgp-l3vpn] D. Jain, et al. "Yang Data Model for BGP/MPLS L3 VPNs", 766 draft-ietf-bess-l3vpn-yang, work in progress. 768 [RFC4364] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private 769 Networks (VPNs)", RFC 4364, February 2006. 771 [ACTN-VN] Y. Lee, et al., "A Yang Data Model for ACTN VN Operation", 772 draft-lee-teas-actn-vn-yang, work in progress. 774 [TSM] Y. Lee, et al., "Traffic Engineering and Service Mapping Yang 775 Model", draft-lee-teas-te-service-mapping-yang, work in 776 progress. 778 [TE-Topo] X. Liu, et al., "YANG Data Model for Traffic Engineering 779 (TE) Topologies", draft-ietf-teas-yang-te-topo, work in 780 progress. 782 [RFC8309] Q. Wu, W. Liu, and A. Farrel, "Service Models Explained", 783 RFC 8309, January 2018. 785 [L3SM] Q. Wu, S. Litkowski, L. Tomotaki, and K. Ogaki, "YANG Data 786 Model for L3VPN Service Delivery", RFC 8299, January 2018. 788 [L2SM] G. Fioccola (Ed), "A YANG Data Model for L2VPN Service 789 Delivery", draft-ietf-l2sm-l2vpn-service-model, work in 790 progress. 792 [ACTN-Telemetry] Y. Lee, et al.," YANG models for ACTN TE 793 Performance Monitoring Telemetry and Network Autonomics", 794 draft-lee-teas-actn-pm-telemetry-autonomics, work in 795 progress. 797 8. Contributors 799 Adrian Farrel 800 Old Dog Consulting 801 Email: adrian@olddog.co.uk 803 Dhruv Dhody 804 Huawei 805 Email: dhruv.dhody@huawei.com 807 Haomian Zheng 808 Huawei 809 Email: haomianzheng@hauwei.com 811 Authors' Addresses 813 Young Lee 814 Huawei Technologies 815 Email: leeyoung@huawei.com 817 Qin Wu 818 Huawei Technologies 819 Email: bill.wu@huawei.com 821 Italo Busi 822 Huawei Technologies 823 Email: Italo.Busi@huawei.com 825 Daniele Ceccarelli 826 Ericsson 827 Email: daniele.ceccarelli@ericsson.com 829 Jeff Tantsura 830 Nuage 831 Email: jefftant.ietf@gmail.com