idnits 2.17.1 draft-lee-teas-actn-poi-applicability-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 4) being 59 lines 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 (June 20, 2019) is 1743 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'TE-Topo' is defined on line 944, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 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 Futurewei 3 Intended status: Informational 4 Expires: December 20, 2019 D. Ceccarelli 5 Ericsson 7 J. Tantsura 8 Apstra 10 June 20, 2019 12 Applicability of ACTN to Support Packet and Optical Integration 14 draft-lee-teas-actn-poi-applicability-00 15 Abstract 17 This document outlines the applicability of Abstraction and 18 Control of Traffic Engineered Networks (ACTN) to Packet & Optical 19 Integration (POI). It also identifies a number of deployment 20 scenarios to support L3VPN and L2VPN in operator's networks and 21 provides implementation guidelines. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with 26 the provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other 35 documents at any time. It is inappropriate to use Internet-Drafts 36 as reference material or to cite them other than as "work in 37 progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on December 20, 2019. 47 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with 55 respect to this document. Code Components extracted from this 56 document must include Simplified BSD License text as described in 57 Section 4.e of the Trust Legal Provisions and are provided without 58 warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction.................................................3 63 1.1. Requirements Language.....................................3 64 2. POI with L2/L3VPN Service Under Single Network Operator Control 65 ................................................................3 66 2.1. L2/L3VPN/VN Service Request by the Customer...............5 67 2.2. Service and Network Orchestration.........................7 68 2.3. IP/MPLS Domain Controller and NE Functions...............10 69 2.3.1. Scenario A: Shared Tunnel Selection.................10 70 2.3.1.1. Domain Tunnel Selection........................11 71 2.3.1.2. VPN/VRF Provisioning for L3VPN.................12 72 2.3.1.3. VSI Provisioning for L2VPN.....................13 73 2.3.1.4. Inter-domain Links Update......................13 74 2.3.1.5. End-to-end Tunnel Management...................13 75 2.3.2. Scenario B: Isolated VN/Tunnel Establishment........14 76 2.4. Optical Domain Controller and NE Functions...............14 77 2.5. Orchestrator-Controllers-NEs Communication Protocol Flows16 78 3. POI with VN Recursion Under Multiple Network Operators Control 79 ...............................................................17 80 3.1. Service Request Process between Multiple Operators.......19 81 3.2. Service/network Orchestration of Operator 2..............19 82 4. Security Considerations.....................................20 83 5. IANA Considerations.........................................21 84 6. Acknowledgements............................................21 85 7. References..................................................21 86 7.1. Normative References.....................................21 87 7.2. Informative References...................................21 88 8. Contributors................................................22 89 Authors' Addresses.............................................22 91 1. Introduction 93 Abstraction and Control of Traffic Engineered Networks (ACTN) 94 describes a set of management and control functions used to 95 operate one or more TE networks to construct virtual networks that 96 can be represented to customers and that are built from 97 abstractions of the underlying TE networks so that, for example, a 98 link in the customer's network is constructed from a path or 99 collection of paths in the underlying networks [RFC8453]. 101 This document outlines the applicability of Abstraction and 102 Control of Traffic Engineered Networks (ACTN) to Packet and 103 Optical Integration. It also identifies a number of deployment 104 scenarios to support POI in operator's networks and provides 105 implementation guidelines. 107 1.1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 110 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 111 in this document are to be interpreted as described in [RFC2119]. 113 2. POI with L2/L3VPN Service Under Single Network Operator Control 115 This section provides a number of deployment scenarios for packet 116 and optical integration (POI). Specifically, this section provides 117 a deployment scenario in which ACTN hierarchy is deployed to 118 control a multi-layer and multi-domain network via two IP/MPLS 119 PNCs and two Optical PNCs with coordination with L-MDSC. This 120 scenario is in the context of an upper layer service configuration 121 (e.g. L3VPN) across two AS domains which are transported by two 122 transport underlay domains (e.g. OTN). 124 The provisioning of the L3VPN service is outside ACTN scope but it 125 is worth showing how the L3VPN service provisioning is integrated 126 for the end-to-end service fulfilment in ACTN context. An example 127 of service configuration function in the Service/Network 128 Orchestrator is discussed in [bess-l3vpn]. 130 Figure 1 shows an ACTN POI Reference Architecture where it shows 131 ACTN components as well as non-ACTN components that are necessary 132 for the end-to-end service fulfilment. Both IP/MPLS and Optical 133 Networks are multi-domain. Each IP/MPLS domain network is 134 controlled by its' domain controller and all the optical domains 135 are controlled by a hierarchy of optical domain controllers. The 136 L-MDSC function of the optical domain controllers provides an 137 abstract view of the whole optical network to the Service/Network 138 Orchestrator. It is assumed that all these components of the 139 network belong to one single network operator domain under the 140 control of the service/network orchestrator. 142 Customer 143 +-------------------------------+ 144 | +-----+ +------------+ | 145 | | CNC |----| Service Op.| | 146 | +-----+ +------------+ | 147 +-------|------------------|----+ 148 | ACTN interface | Non-ACTN interface 149 | CMI | (Customer Service model) 150 Service/Network| +----------------+ 151 Orchestrator | | 152 +------|-----------------------------------|-----------+ 153 | +----------------------------------+ | | 154 | |MDSC TE & Service Mapping Function| | | 155 | +----------------------------------+ | | 156 | | | | | 157 | +------------------+ +---------------------+ | 158 | | MDSC NP Function |-------|Service Config. Func.| | 159 | +------------------+ +---------------------+ | 160 +------|---------------------------|-------------------+ 161 MPI | +---------------------+--+ 162 | / Non-ACTN interface \ 163 +-------+---/-------+------------+ \ 164 IP/MPLS | / |Optical | \ IP/MPLS 165 Domain 1 | / |Domain | \ Domain 2 166 Controller| / |Controller | \ Controller 167 +------|-------/--+ +---|-----+ +--|-----------\----+ 168 | +-----+ +-----+| | +-----+ | |+------+ +------+| 169 | |PNC1 | |Serv.|| | |PNC | | || PNC2 | | Serv.|| 170 | +-----+ +----- | | +-----+ | |+------+ +------+| 171 +-----------------+ +---------+ +-------------------+ 172 SBI | | | SBI 173 v | V 174 +------------------+ | +------------------+ 175 / IP/MPLS Network \ | / IP/MPLS Network \ 176 +----------------------+ | SBI +----------------------+ 177 v 178 +-------------------------------+ 179 / Optical Network \ 180 +-----------------------------------+ 182 Figure 1. ACTN POI Reference Architecture 184 Figure 1 shows ACTN POI Reference Architecture where it depicts: 186 . CMI (CNC-MDSC Interface) interfacing CNC with MDSC function 187 in the Service/Network Orchestrator. This is where TE & 188 Service Mapping [TSM] and either ACTN VN [ACTN-VN] or TE- 189 topology [TE-Topo]model is exchanged over CMI. 191 . Customer Service Model Interface: Non-ACTN interface in the 192 Customer Portal interfacing Service/Network Orchestrator's 193 Service Configuration Function. This is the interface where 194 L3SM information is exchanged. 196 . MPI (MDSC-PNC Interface) interfacing IP/MPLS Domain 197 Controllers and Optical Domain Controllers. 199 . Service Configuration Interface: Non-ACTN interface in 200 Service/Network Orchestrator interfacing with the IP/MPLS 201 Domain Controllers to coordinate L2/L3VPN multi-domain 202 service configuration. This is where service specific 203 information such as VPN, VPN binding policy (e.g., new 204 underlay tunnel creation for isolation), etc. are conveyed. 206 . SBI (South Bound Interface): Non-ACTN interface in the domain 207 controller interfacing network elements in the domain. 209 Please note that MPI and Service Configuration Interface can be 210 implemented as the same interface with the two different 211 capabilities. The split is just functional but doesn't have to be 212 also logical. 214 The following sections are provided to describe key functions that 215 are necessary for the vertical as well as horizontal end-to-end 216 service fulfilment of POI. 218 2.1. L2/L3VPN/VN Service Request by the Customer 220 A customer can request L3VPN services with TE requirements using 221 ACTN CMI models (i.e., ACTN VN YANG, TE & Service Mapping YANG) 222 and non-ACTN customer service models such as L2SM/L3SM YANG 223 together. Figure 2 shows detailed control flow between customer 224 and service/network orchestrator to instantiate L2/L3VPN/VN 225 service request. 227 Customer 228 +-------------------------------------------+ 229 | +-----+ +------------+ | 230 | | CNC |--------------| Service Op.| | 231 | +-----+ +------------+ | 232 +-------|------------------------|----------+ 233 2. VN & TE/Svc | | 1.L2/3SM 234 Mapping | | | 235 | | ^ | | 236 | | | | | 237 v | | 3. Update VN | v 238 | & TE/Svc | 239 Service/Network | mapping | 240 Orchestrator | | 241 +------------------|------------------------|-----------+ 242 | +----------------------------------+ | | 243 | |MDSC TE & Service Mapping Function| | | 244 | +----------------------------------+ | | 245 | | | | | 246 | +------------------+ +---------------------+ | 247 | | MDSC NP Function |-------|Service Config. Func.| | 248 | +------------------+ +---------------------+ | 249 +-------|-----------------------------------|-----------+ 251 NP: Network Provisioning 253 Figure 2. Service Request Process 255 . ACTN VN YANG provides VN Service configuration, as specified in 256 [ACTN-VN]. 258 o It provides the profile of VN in terms of VN members, each 259 of which corresponds to an edge-to-edge link between 260 customer end-points (VNAPs). It also provides the mappings 261 between the VNAPs with the LTPs and between the 262 connectivity matrix with the VN member from which the 263 associated traffic matrix (e.g., bandwidth, latency, 264 protection level, etc.) of VN member is expressed (i.e., 265 via the TE-topology's connectivity matrix). 267 o The model also provides VN-level preference information 268 (e.g., VN member diversity) and VN-level admin-status and 269 operational-status. 271 . L2SM YANG [RFC8466] provides all L2VPN service configuration 272 and site information from a customer/service point of view. 274 . L3SM YANG [RFC8299] provides all L3VPN service configuration 275 and site information from a customer/service point of view. 277 . The TE & Service Mapping YANG model [TE & Service] provides TE- 278 service mapping as well as site mapping. 280 o TE-service mapping provides the mapping of L3VPN instance 281 from [RFC8299] with the corresponding ACTN VN instance. 283 o The TE-service mapping also provides the service mapping 284 requirement type as to how each L2/L3VPN/VN instance is 285 created with respect to the underlay TE tunnels (e.g., 286 whether the L3VPN requires a new and isolated set of TE 287 underlay tunnels or not, etc.). See Section 2.2 for 288 detailed discussion on the mapping requirement types. 290 o Site mapping provides the site reference information 291 across L2/L3VPN Site ID, ACTN VN Access Point ID, and the 292 LTP of the access link. 294 2.2. Service and Network Orchestration 296 The Service/Network orchestrator shown in Figure 1 interfaces the 297 customer and decouples the ACTN MDSC functions from the customer 298 service configuration functions. 300 An implementation can choose to split the Service/Network 301 orchestration functions, as described in [RFC8309] and in section 302 4.2 of [RFC8453], between a top-level Service Orchestrator 303 interfacing the customer and two low-level Network Orchestrators, 304 one controlling a multi-domain IP/MPLS network and the other 305 controlling the Optical networks. 307 Another implementation can choose to combine the L-MDSC functions 308 of the Optical hierarchical controller, providing multi-domain 309 coordination of the Optical network together with the MDSC 310 functions in the Service/Network orchestrator. 312 Without loss of generality, this assumes that the service/network 313 orchestrator as depicted in Figure 1 would include all the 314 required functionalities as in a hierarchical orchestration case. 316 One of the important service functions the Service/Network 317 orchestrator performs is to identify which TE Tunnels should carry 318 the L3VPN traffic (from TE & Service Mapping Model) and to relay 319 this information to the IP/MPLS domain controllers, via non-ACTN 320 interface, to ensure proper IP/VRF forwarding table be populated 321 according to the TE binding requirement for the L3VPN. 323 [Editor's Note: What mechanism would convey on the interface to 324 the IP/MPLS domain controllers as well as on the SBI (between 325 IP/MPLS domain controllers and IP/MPLS PE routers) the TE binding 326 policy dynamically for the L3VPN? Typically, VRF is the function 327 of the device that participate MP-BGP in MPLS VPN. With current 328 MP-BGP implementation in MPLS VPN, the VRF's BGP next hop is the 329 destination PE and the mapping to a tunnel (either an LDP or a BGP 330 tunnel) toward the destination PE is done by automatically without 331 any configuration. It is to be determined the impact on the PE VRF 332 operation when the tunnel is an optical bypass tunnel which does 333 not participate either LDP or BGP. 335 Figure 3 shows service/network orchestrator interactions with 336 various domain controllers to instantiate tunnel provisioning as 337 well as service configuration. 339 +-------|----------------------------------|-----------+ 340 | +----------------------------------+ | | 341 | |MDSC TE & Service Mapping Function| | | 342 | +----------------------------------+ | | 343 | | | | | 344 | +------------------+ +---------------------+ | 345 | | MDSC NP Function |-------|Service Config. Func.| | 346 | +------------------+ +---------------------+ | 347 +-------|------------------------------|---------------+ 348 | | 349 | +-------------------+------+ 3. 350 2. Inter-layer | / \ VPN Serv. 351 tunnel +-----+--------/-------+-----------------+ \provision 352 binding| / | 1. Optical | \ 353 | / | tunnel creation | \ 354 +----|-----------/-+ +---|------+ +-----|-------\---+ 355 | +-----+ +-----+ | | +------+ | | +-----+ +-----+| 356 | |PNC1 | |Serv.| | | | PNC | | | |PNC2 | |Serv.|| 357 | +-----+ +-----+ | | +------+ | | +-----+ +-----+| 358 +------------------+ +----------+ +-----------------+ 360 Figure 3. Service and Network Orchestration Process 362 . TE binding requirement types [TE-service mapping] are: 364 1. Hard Isolation with deterministic latency: Customer would 365 request an L3VPN service [RFC8299] using a set of TE 366 Tunnels with a deterministic latency requirement and that 367 cannot be not shared with other L3VPN services nor compete 368 for bandwidth with other Tunnels. 370 2. Hard Isolation: This is similar to the above case without 371 deterministic latency requirements. 373 3. Soft Isolation: Customer would request an L3VPN service 374 using a set of MPLS-TE tunnel which cannot be shared with 375 other L3VPN services. 377 4. Sharing: Customer would accept sharing the MPLS-TE Tunnels 378 supporting its L3VPN service with other services. 380 For the first three types, there could be additional TE binding 381 requirements with respect to different VN members of the same VN 382 associated with an L3VPN service. For the first two cases, VN 383 members can be hard-isolated, soft-isolated, or shared. For the 384 third case, VN members can be soft-isolated or shared. 386 . When "Hard Isolation with or w/o deterministic latency" (i.e., 387 the first and the second type) TE binding requirement is 388 applied for a L3VPN, a new optical layer tunnel has to be 389 created (Step 1 in Figure 3). This operation requires the 390 following control level mechanisms as follows: 392 o The MDSC function of the Service/Network Orchestrator 393 identifies only the domains in the IP/MPLS layer in which 394 the VPN needs to be forwarded. 396 o Once the IP/MPLS layer domains are determined, the MDSC 397 function of the Service/Network Orchestrator needs to 398 identify the set of optical ingress and egress points of 399 the underlay optical tunnels providing connectivity 400 between the IP/MPLS layer domains. 402 o Once both IP/MPLS layers and optical layer are determined, 403 the MDSC needs to identify the inter-layer peering points 404 in both IP/MPLS domains as well as the optical domain(s). 405 This implies that the L3VPN traffic will be forwarded to 406 an MPLS-TE tunnel that starts at the ingress PE (in one 407 IP/MPLS domain) and terminates at the egress PE (in 408 another IP/MPLS domain) via a dedicated underlay optical 409 tunnel. 411 . The MDSC function of the Service/Network Orchestrator needs to 412 first request the optical L-MDSC to instantiate an optical 413 tunnel for the optical ingress and egress. This is referred to 414 as optical tunnel creation (Step 1 in Figure 3). Note that it 415 is L-MDSC responsibility to perform multi-domain optical 416 coordination with its underlying optical PNCs, for setting up a 417 multi-domain optical tunnel. 419 . Once the optical tunnel is established, then the MDSC function 420 of the Service/Network Orchestrator needs to coordinate with 421 the PNC functions of the IP/MPLS Domain Controllers (under 422 which the ingress and egress PEs belong) the setup of a multi- 423 domain MPLS-TE Tunnel, between the ingress and egress PEs. This 424 setup is carried by the created underlay optical tunnel (Step 2 425 in Figure 3). 427 . It is the responsibility of the Service Configuration Function 428 of the Service/Network Orchestrator to identify 429 interfaces/labels on both ingress and egress PEs and to convey 430 this information to both the IP/MPLS Domain Controllers (under 431 which the ingress and egress PEs belong) for proper 432 configuration of the L3VPN (BGP and VRF function of the PEs) in 433 their domain networks (Step 3 in Figure 3). 435 2.3. IP/MPLS Domain Controller and NE Functions 437 IP/MPLS networks are assumed to have multiple domains and each 438 domain is controlled by IP/MPLS domain controller in which the 439 ACTN PNC functions and non-ACTN service functions are performed by 440 the IP/MPLS domain controller. 442 Among the functions of the IP/MPLS domain controller are VPN 443 service aspect provisioning such as VRF control and management for 444 VPN services, etc. It is assumed that BGP is running in the inter- 445 domain IP/MPLS networks for L2/L3VPN and that the IP/MPLS domain 446 controller is also responsible for configuring the BGP speakers 447 within its control domain if necessary. 449 Depending on the TE binding requirement types discussed in Section 450 2.2., there are two possible deployment scenarios. 452 2.3.1. Scenario A: Shared Tunnel Selection 454 When the L2/L3VPN does not require isolation (either hard or 455 soft), it can select an existing MPLS-TE and Optical tunnel 456 between ingress and egress PE, without creating any new TE 457 tunnels. Figure 4 shows this scenario. 459 IP/MPLS Domain 1 IP/MPLS Domain 2 460 Controller Controller 462 +------------------+ +------------------+ 463 | +-----+ +-----+ | | +-----+ +-----+ | 464 | |PNC1 | |Serv.| | | |PNC2 | |Serv.| | 465 | +-----+ +-----+ | | +-----+ +-----+ | 466 +--|-----------|---+ +--|-----------|---+ 467 | 1.Tunnel | 2.VPN/VRF | 1.Tunnel |2.VPN/VRF 468 | Selection | Provisioning | Selection |Provisioning 469 V V V V 470 +---------------------+ +---------------------+ 471 CE / PE tunnel 1 ASBR\ /ASBR tunnel 2 PE \ CE 472 o--/---o..................o--\--------/--o..................o---\-o 473 \ / \ / 474 \ AS Domain 1 / \ AS Domain 2 / 475 +---------------------+ +---------------------+ 477 End-to-end tunnel 478 <----------------------------------------------------> 480 Figure 4. IP/MPLS Domain Controller & NE Functions 482 How VPN is disseminated across the network is out of the scope of 483 this document. We assume that MP-BGP is running in IP/MPLS 484 networks and VPN is made known to ABSRs and PEs by each IP/MPLS 485 domain controllers. See RFC 4364 [RFC4364] for detailed 486 descriptions on how MP-BGP works. 488 There are several functions IP/MPLS domain controllers need to 489 provide in order to facilitate tunnel selection for the VPN in 490 both domain level and end-to-end level. 492 2.3.1.1. Domain Tunnel Selection 494 Each domain IP/MPLS controller is responsible for selecting its 495 domain level tunnel for the L3VPN. First it needs to determine 496 which existing tunnels would fit for the L2/L3VPN requirements 497 allotted to the domain by the Service/Network Orchestrator (e.g., 498 tunnel binding, bandwidth, latency, etc.). If there are existing 499 tunnels that are feasible to satisfy the L3VPN requirements, the 500 IP/MPLS domain controller selects the optimal tunnel from the 501 candidate pool. Otherwise, an MPLS tunnel with modified bandwidth 502 or a new MPLS Tunnel needs to be setup. Note that with no 503 isolation requirement for the L3VPN, existing MPLS tunnel can be 504 selected. With soft isolation requirement for the L3VPN, an 505 optical tunnel can be shared with other L2/L3VPN services while 506 with hard isolation requirement for the L2/L3VPN, a dedicated 507 MPLS-TE and a dedicated optical tunnel MUST be provisioned for the 508 L2/L3VPN. 510 2.3.1.2. VPN/VRF Provisioning for L3VPN 512 Once the domain level tunnel is selected for a domain, the Service 513 Function of the IP/MPLS domain controller maps the L3VPN to the 514 selected MPLS-TE tunnel and assigns a label (e.g., MPLS label) 515 with the PE. Then the PE creates a new entry for the VPN in the 516 VRF forwarding table so that when the VPN packet arrives to the 517 PE, it will be able to direct to the right interface and PUSH the 518 label assigned for the VPN. When the PE forwards a VPN packet, it 519 will push the VPN label signaled by BGP and, in case of option A 520 and B [RFC4364], it will also push the LSP label assigned to the 521 configured MPLS-TE Tunnel to reach the ASBR next hop and forwards 522 the packet to the MPLS next-hop of this MPLS-TE Tunnel. 524 In case of option C [RFC4364], the PE will push one MPLS LSP label 525 signaled by BGP to reach the destination PE and a second MPLS LSP 526 label assigned to the configured MPLS-TE Tunnel to reach the ASBR 527 next-hop and forward the packet to the MPLS next-hop of this MPLS- 528 TE Tunnel. 530 With Option C, the ASBR of the first domain interfacing the next 531 domain should keep the VPN label intact to the ASBR of the next 532 domain so that the ASBR in the next domain sees the VPN packets as 533 if they are coming from a CE. With Option B, the VPN label is 534 swapped. With option A, the VPN label is removed. 536 With Option A and B, the ASBR of the second domain does the same 537 procedure that includes VPN/VRF tunnel mapping and interface/label 538 assignment with the IP/MPLS domain controller. With option A, the 539 ASBR operations are the same as of the PEs. With option B, the 540 ASBR operates with VPN labels so it can see the VPN the traffic 541 belongs to. With option C, the ASBR operates with the end-to-end 542 tunnel labels so it may be not aware of the VPN the traffic 543 belongs to. 545 This process is repeated in each domain. The PE of the last domain 546 interfacing the destination CE should recognize the VPN label when 547 the VPN packets arrive and thus POP the VPN label and forward the 548 packets to the CE. 550 2.3.1.3. VSI Provisioning for L2VPN 552 The VSI provisioning for L2VPN is similar to the VPN/VRF provision 553 for L3VPN. L2VPN service types include: 555 o Point-to-point Virtual Private Wire Services (VPWSs) that use 556 LDP-signaled Pseudowires or L2TP-signaled Pseudowires [RFC6074]; 558 o Multipoint Virtual Private LAN Services (VPLSs) that use LDP- 559 signaled Pseudowires or L2TP-signaled Pseudowires [RFC6074]; 561 o Multipoint Virtual Private LAN Services (VPLSs) that use a Border 562 Gateway Protocol (BGP) control plane as described in [RFC4761] 563 And [RFC6624]; 565 o IP-Only LAN-Like Services (IPLSs) that are a functional subset of 566 VPLS services [RFC7436]; 568 o BGP MPLS-based Ethernet VPN Services as described in [RFC7432] 569 and [RFC7209]; 571 o Ethernet VPN VPWS specified in [RFC8214] and [RFC7432]. 573 2.3.1.4. Inter-domain Links Update 575 In order to facilitate inter-domain links for the VPN, we assume 576 that the service/network orchestrator would know the inter-domain 577 link status and its resource information (e.g., bandwidth 578 available, protection/restoration policy, etc.) via some 579 mechanisms (which are beyond the scope of this document). We also 580 assume that the inter-domain links are pre-configured prior to 581 service instantiation. 583 2.3.1.5. End-to-end Tunnel Management 585 It is foreseen that the Service/Network orchestrator should 586 control and manage end-to-end tunnels for VPNs per VPN policy. 588 As discussed in [ACTN-PM], the Orchestrator is responsible to 589 collect domain LSP-level performance monitoring data from domain 590 controllers and to derive and report end-to-end tunnel performance 591 monitoring information to the customer. 593 2.3.2. Scenario B: Isolated VN/Tunnel Establishment 595 When the L3VPN requires hard-isolated Tunnel establishment, 596 optical layer tunnel binding with IP/MPLS layer is necessary. As 597 such, the following functions are necessary. 599 . The IP/MPLS Domain Controller of Domain 1 needs to send the VRF 600 instruction to the PE: 602 o To the Ingress PE of AS Domain 1: Configuration for each 603 L3VPN destination IP address (in this case the remote CE's 604 IP address for the VPN or any customer's IP addresses 605 reachable through a remote CE) of the associated VPN label 606 assigned by the Egress PE and of the MPLS-TE Tunnel to be 607 used to reach the Egress PE: so that the proper VRF table 608 is populated to forward the VPN traffic to the inter-layer 609 optical interface with the VPN label. 611 . The Egress PE, upon the discovery of a new IP address, needs to 612 send the mapping information (i.e., VPN to IP address) to its' 613 IP/MPLS Domain Controller of Domain 2 which sends, in turn, to 614 the service orchestrator. The service orchestrator would then 615 propagate this mapping information to the IP/MPLS Domain 616 Controller of Domain 1 which sends it, in turn, to the ingress 617 PE so that it may override the VPN/VRF forwarding or VSI 618 forwarding, respectively for L3VPN and L2VPN. As a result, when 619 packets arriving at the ingress PE with that IP destination 620 address, the ingress PE would then forward this packet to the 621 inter-layer optical interface. 623 [Editor's Note: in case of hard isolated tunnel required for the 624 VPN, we need to create a separate MPLS TE tunnel and encapsulate 625 the MPLS packets of the MPLS Tunnel into the ODU so that the 626 optical NE would route this MPLS Tunnel to a separate optical 627 tunnel from other tunnels.] 629 2.4. Optical Domain Controller and NE Functions 631 Optical network provides the underlay connectivity services to 632 IP/MPLS networks. The multi-domain optical network coordination is 633 performed by the L-MDSC function shown in Figure 1 so that the 634 whole multi-domain optical network appears to the service/network 635 orchestrator as one optical network. The coordination of 636 Packet/Optical multi-layer and IP/MPLS multi-domain is done by the 637 service/network orchestrator where it interfaces two IP/MPLS 638 domain controllers and one optical L-MDSC. 640 Figure 5 shows how the Optical Domain Controllers create a new 641 optical tunnel and the related interaction with IP/MPLS domain 642 controllers and the NEs to bind the optical tunnel with proper 643 forwarding instruction so that the VPN requiring hard isolation 644 can be fulfilled. 646 IP/MPLS Domain 1 Optical Domain IP/MPLS Domain 2 647 Controller Controller Controller 649 +------------------+ +---------+ +------------------+ 650 | +-----+ +-----+ | | +-----+ | | +-----+ +-----+ | 651 | |PNC1 | |Serv.| | | |PNC | | | |PNC2 | |Serv.| | 652 | +-----+ +-----+ | | +-----+ | | +-----+ +-----+ | 653 +--|-----------|---+ +----|----+ +--|----------|----+ 654 | 2.Tunnel | 3.VPN/VRF | |2.Tunnel |3.VPN/VRF 655 | Binding | Provisioning| |Binding |Provisioning 656 V V | V V 657 +-------------------+ | +-------------------+ 658 CE / PE ASBR\ | /ASBR PE \ CE 659 o--/---o o--\----|--/--o o---\--o 660 \ : / | \ : / 661 \ : AS Domain 1 / | \ AS Domain 2 : / 662 +-:-----------------+ | +-----------------:-+ 663 : | : 664 : | 1. Optical : 665 : | Tunnel Creation : 666 : v : 667 +-:--------------------------------------------------:-+ 668 / : : \ 669 / o..................................................o \ 670 | Optical Tunnel | 671 \ / 672 \ Optical Domain / 673 +------------------------------------------------------+ 675 Figure 5. Domain Controller & NE Functions (Isolated Optical 676 Tunnel) 678 . As discussed in 2.2., in case that VPN has requirement for 679 hard-isolated tunnel establishment, the service/network 680 orchestrator will coordinate across IP/MPLS domain 681 controllers and Optical L-MDSC to ensure the creation of a 682 new optical tunnel for the VPN in proper sequence. Figure 683 5 shows this scenario. 685 o The MDSC of the service/network orchestrator requests 686 the L-MDSC to setup and Optical tunnel providing 687 connectivity between the inter-layer interfaces at 688 the ingress and egress PEs and requests the two 689 IP/MPLS domain controllers to setup an inter-domain 690 IP link between these interfaces 692 o The MDSC of the service/network orchestrator then 693 should provide the ingress IP/MPLS domain controller 694 with the routing instruction for the VPN so that the 695 ingress IP/MPLS domain controller would help its 696 ingress PE to populate forwarding table. The packet 697 with the VPN label should be forwarded to the optical 698 interface the MDSC provided. 700 The Ingress Optical Domain PE needs to recognize MPLS-TE 701 label on its ingress interface from IP/MPLS domain PE and 702 encapsulate the MPLS packets of this MPLS-TE Tunnel into 703 the ODU. 704 [Editor's Note: We assumed that the Optical PE is LSR.] 706 . The Egress Optical Domain PE needs to POP the ODU label 707 before sending the packet (with MPLS-TE label kept intact 708 at the top level) to the Egress PE in the IP/MPLS Domain 709 to which the packet is destined. 711 [Editor's Note: If there are two VPNs having the same destination 712 CE requiring non-shared optical tunnels from each other, we need 713 to explain this case with a need for additional Label to 714 differentiate the VPNs] 716 2.5. Orchestrator-Controllers-NEs Communication Protocol Flows 718 This section provides generic communication protocol flows across 719 orchestrator, controllers and NEs in order to facilitate the POI 720 scenarios discussed in Section 2.3.2 for dynamic optical Tunnel 721 establishment. Figure 6 shows the communication flows. 723 +---------+ +-------+ +------+ +------+ +------+ +------+ 724 |Orchestr.| |Optical| |Packet| |Packet| |Ing.PE| |Egr.PE| 725 | | | Ctr. | |Ctr-D1| |Ctr-D2| | D1 | | D2 | 726 +---------+ +-------+ +------+ +------+ +------+ +------+ 727 | | | | | | 728 | | | | |<--BGP--->| 729 | | | |VPN Update | | 730 | | | VPN Update|<---------------------| 731 |<--------------------------------------|(Dest, VPN)| | 732 | | |(Dest, VPN)| | | 733 | Tunnel Create | | | | | 734 |---------------->| | | | | 735 |(VPN,Ingr/Egr if)| | | | | 736 | | | | | | 737 | Tunnel Confirm | | | | | 738 |<----------------| | | | | 739 | (Tunnel ID) | | | | | 740 | | | | | | 741 | Tunnel Bind | | | | | 742 |-------------------------->| | | | 743 | (Tunnel ID, VPN, Ingr if) | Forward. Mapping | | 744 | | |---------------------->| (1) | 745 | Tunnel Bind Confirm | (Dest, VPN, Ingr if | | 746 |<--------------------------| | | | 747 | | | | | | 748 | Tunnel Bind | | | | | 749 |-------------------------------------->| | | 750 | (Tunnel ID, VPN, Egr if) | | | | 751 | | | | Forward. Mapping (2)| 752 | | | |--------------------->| 753 | | | | (Dest, VPN , Egr if) | 754 | | Tunnel Bind Confirm | | | 755 |<--------------------------------------| | | 756 | | | | | | 758 Figure 6. Communication Flows for Optical Tunnel Establishment 759 and binding. 761 When Domain Packet Controller 1 sends the forwarding mapping 762 information as indicated in (1) in Figure 6, the Ingress PE in 763 Domain 1 will need to provision the VRF forwarding table based on 764 the information it receives. Please see the detailed procedure in 765 Section 2.3.1.2. A similar procedure is to be done at the Egress 766 PE in Domain 2. 768 3. POI with VN Recursion Under Multiple Network Operators Control 770 [RFC8453] briefly introduces a case for the VN supplied to a 771 customer may be built using resources from different technology 772 layers operated by different operators. For example, one operator 773 may run a packet TE network and use optical connectivity provided 774 by another operator. 776 Figure 7 extracted from [RFC8453] shows the case where a customer 777 asks for end-to-end connectivity between CE A and CE B, a virtual 778 network. The customer's CNC makes a request to Operator 1's MDSC. 779 The MDSC works out which network resources need to be configured 780 and sends instructions to the appropriate PNCs. However, the link 781 between Q and R is a virtual link supplied by Operator 2: Operator 782 1 is a customer of Operator 2. 784 To support this, Operator 1 has a CNC that communicates with 785 Operator 2's MDSC. Note that Operator 1's CNC in Figure 10 is a 786 functional component that does not dictate implementation: it may 787 be embedded in a PNC. 789 Virtual CE A o===============================o CE B 790 Network 792 ----- CNC wants to create 793 Customer | CNC | a VN between CE A 794 ----- and CE B 795 : 796 *********************************************** CMI 797 : 798 Operator 1 --------------------------- 799 | MDSC | 800 --------------------------- 801 : : : 802 : : : 803 ----- ------------- ----- 804 | PNC | | PNC | | PNC | 805 ----- ------------- ----- 806 : : : : : 807 Higher v v : v v 808 Layer CE A o---P-----Q===========R-----S---o CE B 809 Network | : | 810 | : | 811 | ----- | 812 | | CNC | | CNC wants to create 813 | ----- | a VN between Q and R 814 | : | 815 *********************************************** CMI 816 | : | 817 Operator 2 | ------ | 818 | | MDSC | | 819 | ------ | 820 | : | 821 | ------- | 822 | | PNC | | 823 | ------- | 824 \ : : : / 825 Lower \v v v/ 826 Layer X--Y--Z 827 Network 829 Where 831 --- is a link 832 === is a virtual link 834 Figure 7: VN Recursion with Network Layers 836 The CMI in Figure 7 interfaces Operator 1's CNC with Operator 2's 837 MDSC. The functions to perform and the information carried over 838 the inter-operator CMI are identical to those of the Customer's 839 CNC and Operator 1's MDSC. In other words, the two CMIs depicted 840 in Figure 7 are recursive in nature. 842 3.1. Service Request Process between Multiple Operators 844 As discussed previously, the reclusiveness principle applies 845 seamlessly over the two CMIs. This implies that Operator 1's MDSC 846 needs to pass all customer service requirements transparently to 847 Operator 2's MDSC so that Operator 2 should provision its underlay 848 network tunnels to meet the service requirements of the original 849 customer. The MDSC of Operator 1 should translate/map the original 850 customer's intent and service requirements and pass down to the 851 corresponding PNC(s) which is(are) responsible for interfacing 852 another operator (in this example, Operator 2) that provides 853 transport services for the segment of the customer's VN. The PNC 854 in turn performs as a CNC when interfacing its southbound with 855 Operator 2's MDSC. 857 It is possible that additional recursive relationships may also 858 exist between Operator 2 and other operators. 860 3.2. Service/network Orchestration of Operator 2 861 Operator 2 that provides transport service for Operator 1 may also 862 need to perform service/network orchestration function just as the 863 case for Operator 1. 865 4. Security Considerations 867 From a security and reliability perspective, ACTN may encounter 868 many risks such as malicious attack and rogue elements attempting 869 to connect to various ACTN components. Furthermore, some ACTN 870 components represent a single point of failure and threat vector 871 and must also manage policy conflicts and eavesdropping of 872 communication between different ACTN components. 874 All protocols used to realize the ACTN framework should have rich 875 security features, and customer, application and network data 876 should be stored in encrypted data stores. Additional security 877 risks may still exist. Therefore, discussion and applicability of 878 specific security functions and protocols will be better described 879 in documents that are use case and environment specific. 881 The CMI will likely be an external protocol interface. Suitable 882 authentication and authorization of each CNC connecting to the 883 MDSC will be required; especially, as these are likely to be 884 implemented by different organizations and on separate functional 885 nodes. Use of the AAA-based mechanisms would also provide role- 886 based authorization methods so that only authorized CNC's may 887 access the different functions of the MDSC. 889 Where the MDSC must interact with multiple (distributed) PNCs, a 890 PKI-based mechanism is suggested, such as building a TLS or HTTPS 891 connection between the MDSC and PNCs, to ensure trust between the 892 physical network layer control components and the MDSC. Trust 893 anchors for the PKI can be configured to use a smaller (and 894 potentially non-intersecting) set of trusted Certificate 895 Authorities (CAs) than in the Web PKI. Which MDSC the PNC exports 896 topology information to, and the level of detail (full or 897 abstracted), should also be authenticated, and specific access 898 restrictions and topology views should be configurable and/or 899 policy based. 901 5. IANA Considerations 903 This document has no IANA actions. 905 6. Acknowledgements 907 The authors thank Adrian Farrel for useful discussions and their 908 suggestions for this work. 910 7. References 912 7.1. Normative References 914 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 915 Requirement Levels", RFC 2119, March 1997. 917 [RFC8453] D. Ceccarelli and Y. Lee, "Framework for Abstraction and 918 Control of Transport Networks", RFC 8453, August 2018. 920 7.2. Informative References 922 [bgp-l3vpn] D. Jain, et al. "Yang Data Model for BGP/MPLS L3 VPNs", 923 draft-ietf-bess-l3vpn-yang, work in progress. 925 [RFC4364] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private 926 Networks (VPNs)", RFC 4364, February 2006. 928 [RFC4761] K. Kompella, Ed., Y. Rekhter, Ed., "Virtual Private LAN 929 Service (VPLS) Using BGP for Auto-Discovery and 930 Signaling", RFC 4761, January 2007. 932 [ACTN-VN] Y. Lee, et al., "A Yang Data Model for ACTN VN Operation", 933 draft-ietf-teas-actn-vn-yang, work in progress. 935 [TSM] Y. Lee, et al., "Traffic Engineering and Service Mapping Yang 936 Model", draft-ietf-teas-te-service-mapping-yang, work in 937 progress. 939 [ACTN-PM] Y. Lee, et al., "YANG models for VN & TE Performance 940 Monitoring Telemetry and Scaling Intent Autonomics", 941 draft-lee-teas-actn-pm-telemetry-autonomics, work in 942 progress. 944 [TE-Topo] X. Liu, et al., "YANG Data Model for Traffic Engineering 945 (TE) Topologies", draft-ietf-teas-yang-te-topo, work in 946 progress. 948 [RFC6074] E. Rosen, B. Davie, V. Radoaca, and W. Luo, "Provisioning, 949 Auto-Discovery, and Signaling in Layer 2 Virtual Private 950 Networks (L2VPNs)", RFC 6074, January 2011. 952 [RFC6624] K. Kompella, B. Kothari, and R. Cherukuri, "Layer 2 953 Virtual Private Networks Using BGP for Auto-Discovery and 954 Signaling", RFC 6624, May 2012. 956 [RFC7209] A. Sajassi, R. Aggarwal, J. Uttaro, N. Bitar, W. 957 Henderickx, and A. Isaac, "Requirements for Ethernet VPN 958 (EVPN)", RFC 7209, May 2014. 960 [RFC7432] A. Sajassi, Ed., et al., "BGP MPLS-Based Ethernet VPN", 961 RFC 7432, February 2015. 963 [RFC7436] H. Shah, E. Rosen, F. Le Faucheur, and G. Heron, "IP-Only 964 LAN Service (IPLS)", RFC 7436, January 2015. 966 [RFC8214] S. Boutros, A. Sajassi, S. Salam, J. Drake, and J. 967 Rabadan, "Virtual Private Wire Service Support in Ethernet 968 VPN", RFC 8214, August 2017. 970 [RFC8309] Q. Wu, W. Liu, and A. Farrel, "Service Model Explained", 971 RFC 8309, January 2018. 973 [RFC8299] Q. Wu, S. Litkowski, L. Tomotaki, and K. Ogaki, "YANG Data 974 Model for L3VPN Service Delivery", RFC 8299, January 2018. 976 [RFC8466] G. Fioccola, ed., "A YANG Data Model for Layer 2 Virtual 977 Private Network (L2VPN) Service Delivery", RFC8466, 978 October 2018. 980 8. Contributors 982 Authors' Addresses 984 Y. Lee 985 Futurewei Technologies 986 Email: younglee.tx@gmail.com 988 D. Ceccarelli 989 Ericsson 990 Email: daniele.ceccarelli@ericsson.com 992 J. Tantsura 993 Apstra 994 Email: jefftant.ietf@gmail.com