idnits 2.17.1 draft-peru-teas-actn-poi-applicability-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2019) is 1639 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group Fabio Peruzzini 2 Internet Draft TIM 3 Intended status: Informational Italo Busi 4 Huawei 5 Daniel King 6 Old Dog Consulting 7 Sergio Belotti 8 Nokia 9 Gabriele Galimberti 10 Cisco 12 Expires: April 2020 October 31, 2019 14 Applicability of Abstraction and Control of Traffic Engineered 15 Networks (ACTN) to Packet Optical Integration (POI) 17 draft-peru-teas-actn-poi-applicability-02.txt 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on April 31, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 Abstract 59 This document considers the applicability of ACTN to Packet Optical 60 Integration (POI) and IP and Optical DWDM domain internetworking, 61 and specifically the YANG models being defined by the IETF to 62 support this deployment architecture. 64 In this document we highlight the IETF protocols and data models 65 that may be used for the ACTN and control of POI networks, with 66 particular focus on the interfaces between the MDSC (Multi-Domain 67 Service Coordinator) and the underlying Packet and Optical Domain 68 Controllers (P-PNC and O-PNC) to support Packet Optical Integration 69 (POI) use cases. 71 Table of Contents 73 1. Introduction...................................................3 74 2. Reference Scenario.............................................4 75 2.1. Generic Assumptions.......................................6 76 3. Scenario 1 - Multi-Layer Topology Coordination.................7 77 3.1. Discovery of existing Och, ODU, IP links, IP tunnels and 78 IP services...............................................7 79 3.1.1. Common YANG models used at the MPIs..................7 80 3.1.1.1. YANG models used at the Optical MPIs............8 81 3.1.1.2. Required YANG models at the Packet MPIs.........8 82 3.1.2. Inter-domain link Discovery..........................9 83 3.2. Provisioning of an IP Link/LAG over DWDM.................10 84 3.2.1. YANG models used at the MPIs........................10 85 3.2.1.1. YANG models used at the Optical MPIs...........10 86 3.2.1.2. Required YANG models at the Packet MPIs........11 88 3.2.2. IP Link Setup Procedure.............................11 89 3.3. Provisioning of an IP link/LAG over DWDM with path 90 constraints...................................................12 91 3.3.1. YANG models used at the MPIs........................12 92 3.4. Provisioning of an additional link member to an existing 93 LAG with or without path constraints.....................12 94 3.4.1. YANG models used at the MPIs........................13 95 4. Multi-Layer Recovery Coordination.............................13 96 4.1. Ensuring Network Resiliency during Maintenance Events....13 97 4.2. Router port failure......................................13 98 5. Security Considerations.......................................14 99 6. Operational Considerations....................................14 100 7. IANA Considerations...........................................15 101 8. References....................................................15 102 8.1. Normative References.....................................15 103 8.2. Informative References...................................16 104 9. Acknowledgments...............................................16 105 10. Authors' Addresses...........................................16 107 1. Introduction 109 Packet Optical Integration (POI) is an advanced use case of traffic 110 engineering. In wide area networks, a packet network based on the 111 Internet Protocol (IP) and possibly Multiprotocol Label Switching 112 (MPLS) is typically realized on top of an optical transport network 113 that uses Dense Wavelength Division Multiplexing (DWDM). In many 114 existing network deployments, the packet and the optical networks 115 are engineered and operated independently of each other. There are 116 technical differences between the technologies (e.g., routers vs. 117 optical switches) and the corresponding network engineering and 118 planning methods (e.g., inter-domain peering optimization in IP vs. 119 dealing with physical impairments in DWDM, or very different time 120 scales). In addition, customers and customer needs can be different 121 between a packet and an optical network, and it is not uncommon to 122 use different vendors in both domains. Last but not least, state-of- 123 the-art packet and optical networks use sophisticated but complex 124 technologies, and for a network engineer it may not be trivial to be 125 a full expert in both areas. As a result, packet and optical 126 networks are often operated in technical and organizational silos. 128 This separation is inefficient for many reasons. Both capital 129 expenditure (CAPEX) and operational expenditure (OPEX) could be 130 significantly reduced by better integrating the packet and the 131 optical network. Multi-layer online topology insight can speed up 132 troubleshooting (e.g., alarm correlation) and network operation 133 (e.g., coordination of maintenance events), multi-layer offline 134 topology inventory can improve service quality (e.g., detection of 135 diversity constraint violations) and multi-layer traffic engineering 136 can use the available network capacity more efficiently (e.g., 137 coordination of restoration). In addition, provisioning workflows 138 can be simplified or automated as needed across layers (e.g, to 139 achieve bandwidth on demand, or to perform maintenance events). 141 Fully leveraging these benefits requires an integration between the 142 management and control of the packet and the optical network. The 143 Abstraction and Control of TE Networks (ACTN) framework defines 144 functions and interfaces between a Multi-Domain Service Coordinator 145 (MDSC) and Provisioning Network Controllers (PNCs) that can be used 146 for coordinating the packet and optical layers. 148 In this document, key use cases for Packet Optical Integration (POI) 149 are described both from the point of view of the optical and the 150 packet layer. The objective is to explain the benefit and the impact 151 for both the packet and the optical layer, and to identify the 152 required interaction between both layers. Precise definitions of use 153 cases can help with achieving a common understanding across 154 different disciplines. The focus of the use cases are IP networks 155 operated as client of optical DWDM networks. The use cases are 156 ordered by increasing level of integration and complexity. For each 157 multi-layer use case, the document analyzes how to use the 158 interfaces and data models of the ACTN architecture. 160 Understanding the level of standardization and the gaps will help to 161 better assess the feasibility of integration between IP and Optical 162 DWDM domain, in an end-to-end multi-vendor service provisioning 163 perspective. 165 2. Reference Scenario 167 This document is considering a network scenario with multiple 168 Optical domains and multiple Packet domains. 170 Figure 1 shows this scenario in case of two Optical domains and two 171 Packet domains: 173 +----------+ 174 | MDSC | 175 +-----+----+ 176 | 177 +-----------+-----+------+-----------+ 178 | | | | 179 +----+----+ +----+----+ +----+----+ +----+----+ 180 | P-PNC 1 | | O-PNC 1 | | O-PNC 2 | | P-PNC 2 | 181 +----+----+ +----+----+ +----+----+ +----+----+ 182 | | | | 183 | \ / | 184 +-------------------+ \ / +-------------------+ 185 CE / PE ASBR \ | / / ASBR PE \ CE 186 o--/---o o---\-|-------|--/---o o---\--o 187 \ : : / | | \ : : / 188 \ : AS Domain 1 : / | | \ : AS Domain 2 : / 189 +-:---------------:-+ | | +-:---------------:--+ 190 : : | | : : 191 : : | | : : 192 +-:---------------:------+ +-------:---------------:--+ 193 / : : \ / : : \ 194 / o...............o \ / o...............o \ 195 \ Optical Domain 1 / \ Optical Domain 2 / 196 \ / \ / 197 +------------------------+ +--------------------------+ 199 Figure 1 - Reference Scenario 201 The ACTN architecture, defined in [RFC8453], is used to control this 202 multi-domain network where each Packet PNC (P-PNC) is responsible 203 for controlling its IP domain (AS), and each Optical PNC (O-PNC) is 204 responsible for controlling its Optical Domain. The MDSC is 205 responsible for coordinating the whole multi-domain multi-layer 206 (Packet and Optical) network. A specific standard interface (MPI) 207 permits MDSC to interact with the different Provisioning Network 208 Controller (O/P-PNCs). The MPI interface presents an abstracted 209 topology to MDSC hiding technology-specific aspects of the network 210 and hiding topology details depending on the policy chosen regarding 211 the level of abstraction supported. The level of abstraction can be 212 obtained based on P-PNC and O-PNC configuration parameters (e.g. 213 provide the potential connectivity between any PE and any ABSR in an 214 MPLS-TE network). 216 The MDSC in Figure 1 is responsible for multi-domain and multi-layer 217 coordination acrosso multiple Packet and Optical domains, as well as 218 to provide IP services to different CNCs at its CMIs (e.g., using 219 L2SM, L3SM). 221 The multi-domain coordination mechanisms for the IP tunnels 222 supporting these IP services are outside the scope of this document 223 and described in [ACTN-VPN]. In some cases, the MDSC could also rely 224 on the multi-layer Packet Optical Integration mechanisms, described 225 in this draft, to support multi-layer optimizations for these IP 226 services and tunnels. 228 In the network scenario of Figure 1, it is assumed that: 230 o The domain boundaries between the IP and Optical domains are 231 congruent. In other words, one Optical domain supports 232 connectivity between Routers in one and only one Packet Domain. 234 o Inter-domain links exist only between Packet domains (i.e., 235 between ASBR routers) and between Packet and Optical domains 236 (i.e., between routers and ROADMs). In other words, there are no 237 inter-domain links between Optical domains 239 o The interfaces between the routers and the ROADM's are "Ethernet" 240 physical interfaces 242 o The interfaces between the ASBR routers are "Ethernet" physical 243 interfaces 245 2.1. Generic Assumptions 247 This section describes general assumptions which are applicable at 248 all the MPI interfaces, between each PNC (Optical or Packet) and the 249 MDSC, and also to all the scenarios discussed in this document. 251 The data models used on these interfaces are assumed to use the YANG 252 1.1 Data Modeling Language, as defined in [RFC7950]. 254 The RESTCONF protocol, as defined in [RFC8040], using the JSON 255 representation, defined in [RFC7951], is assumed to be used at these 256 interfaces. 258 As required in [RFC8040], the "ietf-yang-library" YANG module 259 defined in [RFC8525] is used to allow the MDSC to discover the set 260 of YANG modules supported by each PNC at its MPI. 262 3. Scenario 1 - Multi-Layer Topology Coordination 264 In this scenario, the MSDC needs to discover the network topology, 265 at both WDM and IP layers, in terms of nodes (NEs) and links, 266 including inter AS domain links as well as cross-layer links. 268 Each PNC provides to the MDSC an abstract topology view of the WDM 269 or of the IP topology of the domain it controls. This topology is 270 abstracted in the sense that some detailed NE information is hidden 271 at the MPI, and all or some of the NEs and related physical links 272 are exposed as abstract nodes and logical (virtual) links, depending 273 on the level of abstraction the user want. This detailed information 274 is key to understand both the inter-AS domain links (seen by each 275 controller as UNI interfaces but as I-NNI interfaces by the MDSC) as 276 well as the cross-layer mapping between IP and WDM layer. 278 The MDSC also maintains an up-to-date network inventory of both IP 279 and WDM layers through the use of IETF notifications through MPI 280 with the PNCs. 282 For the cross-layer links it is key for MDSC to be able to correlate 283 automatically the information about the physical ports from the 284 routers (single link or bundle links for LAG) to client ports in the 285 ROADM. 287 3.1. Discovery of existing Och, ODU, IP links, IP tunnels and IP 288 services 290 In this scenarios MDSC must be able to automatically discover 291 network topology of both WDM and IP layers (links and NE, links 292 between two domains). 294 o An abstract view of the WDM and IP topology must be available. 296 o MDSC must keep an up-to-date network inventory of both IP and WDM 297 layers and it should be possible to correlate such information 298 (e.g.: which port, lambda/OTSi, direction is used by a specific 299 IP service on the WDM equipment). 301 o It should be possible at MDSC level to easily correlate WDM and 302 IP layers alarms to speed-up troubleshooting. 304 3.1.1. Common YANG models used at the MPIs 306 Both Optical and Packet PNCs use the following common topology YANG 307 models at the MPI to report their abstract topologies: 309 o The Base Network Model, defined in the "ietf-network" YANG module 310 of [RFC8345] 312 o The Base Network Topology Model, defined in the "ietf-network- 313 topology" YANG module of [RFC8345], which augments the Base 314 Network Model 316 o The TE Topology Model, defined in the "ietf-te-topology" YANG 317 module of [TE-TOPO], which augments the Base Network Topology 318 Model 320 These common YANG models are generic and augmented by technology- 321 specific YANG modules as described in the following sections. 323 3.1.1.1. YANG models used at the Optical MPIs 325 The Optical PNC also uses at least the following technology-specific 326 topology YANG models, providing WDM and Ethernet technology-specific 327 augmentations of the generic TE Topology Model: 329 o The WSON Topology Model, defined in the "ietf-wson-topology" YANG 330 modules of [WSON-TOPO], or the Flexi-grid Topology Model, defined 331 in the "ietf-flexi-grid-topology" YANG module of [Flexi-TOPO]. 333 o The Ethernet Topology Model, defined in the "ietf-eth-te- 334 topology" YANG module of [CLIENT-TOPO] 336 The WSON Topology Model or, alternatively, the Flexi-grid Topology 337 model is used to report the DWDM network topology (e.g., ROADMs and 338 links) depending on whether the DWDM optical network is based on 339 fixed grid or flexible-grid. 341 The Ethernet Topology is used to report the access links between the 342 IP routers and the edge ROADMs. 344 3.1.1.2. Required YANG models at the Packet MPIs 346 The Packet PNC also uses at least the following technology-specific 347 topology YANG models, providing IP and Ethernet technology-specific 348 augmentations of the generic Topology Models: 350 o The L3 Topology Model, defined in the "ietf-l3-unicast-topology" 351 YANG modules of [RFC8346], which augments the Base Network 352 Topology Model 354 o The Ethernet Topology Model, defined in the "ietf-eth-te- 355 topology" YANG module of [CLIENT-TOPO], which augments the TE 356 Topology Model 358 The Ethernet Topology Model is used to report the access links 359 between the IP routers and the edge ROADMs as well as the 360 inter-domain links between ASBRs, while the L3 Topology Model is 361 used to report the IP network topology (e.g., IP routers and links). 363 3.1.2. Inter-domain link Discovery 365 In the reference network of Figure 1, there are two types of 366 inter-domain links: 368 o Links between two IP domains (ASes) 370 o Links between an IP router and a ROADM 372 Both types of links are Ethernet physical links. 374 The inter-domain link information is reported to the MDSC by the two 375 adjacent PNCs, controlling the two ends of the inter-domain link. 377 The MDSC can understand how to merge these inter-domain links 378 together using the plug-id attribute defined in the TE Topology 379 Model [TE-TOPO], as described in as described in section 4.3 of [TE- 380 TOPO]. 382 A more detailed description of how the plug-id can be used to 383 discover inter-domain link is also provided in section 5.1.4 of 384 [TNBI]. 386 Both types of inter-domain links are discovered using the plug-id 387 attributes reported in the Ethernet Topologies exposed by the two 388 adjacent PNCs. The MDSC can also discover an inter-domain IP 389 link/adjacency between the two IP LTPs, reported in the IP 390 Topologies exposed by the two adjacent P-PNCs, supported by the two 391 ETH LTPs of an Ethernet Link discovered between these two P-PNCs. 393 Two options are possible to discover these inter-domain links: 395 1. Static configuration 397 2. LLDP [IEEE 802.1AB] automatic discovery 398 Since the static configuration requires an administrative burden to 399 configure network-wide unique identifiers, the automatic discovery 400 solution based on LLDP is preferable when LLDP is supported. 402 As outlined in [TNBI], the encoding of the plug-id namespace as well 403 as of the LLDP information within the plug-id value is 404 implementation specific and needs to be consistent across all the 405 PNCs. 407 3.2. Provisioning of an IP Link/LAG over DWDM 409 In this scenario, the MSDC needs to coordinate the creation of an IP 410 link, or a LAG, between two routers through a DWDM network. 412 It is assumed that the MDSC has already discovered the whole network 413 topology as described in section 3.1. 415 3.2.1. YANG models used at the MPIs 417 3.2.1.1. YANG models used at the Optical MPIs 419 The Optical PNC uses at least the following YANG models: 421 o The TE Tunnel Model, defined in the "ietf-te" YANG module of 422 [TE-TUNNEL] 424 o The WSON Tunnel Model, defined in the "ietf-wson-tunnel" YANG 425 modules of [WSON-TUNNEL], or the Flexi-grid Media Channel Model, 426 defined in the "ietf-flexi-grid-media-channel" YANG module of 427 [Flexi-MC] 429 o The Ethernet Client Signal Model, defined in the "ietf-eth-tran- 430 service" YANG module of [CLIENT-SIGNAL] 432 The TE Tunnel model is generic and augmented by technology-specific 433 models such as the WSON Tunnel Model and the Flexi-grid Media 434 Channel Model. 436 The WSON Tunnel Model or, alternatively, the Flexi-grid Media 437 Channel Model are used to setup connectivity within the DWDM network 438 depending on whether the DWDM optical network is based on fixed grid 439 or flexible-grid. 441 The Ethernet Client Signal Model is used to configure the steering 442 of the Ethernet client traffic between Ethernet access links and TE 443 Tunnels, which in this case could be either WSON Tunnels or 444 Flexi-Grid Media Channels. This model is generic and applies to any 445 technology-specific TE Tunnel: technology-specific attributes are 446 provided by the technology-specific models which augment the generic 447 TE-Tunnel Model. 449 3.2.1.2. Required YANG models at the Packet MPIs 451 The Packet PNC uses at least the following topology YANG models: 453 o The Base Network Model, defined in the "ietf-network" YANG module 454 of [RFC8345] (see section 3.1.1) 456 o The Base Network Topology Model, defined in the "ietf-network- 457 topology" YANG module of [RFC8345] (see section 3.1.1) 459 o The L3 Topology Model, defined in the "ietf-l3-unicast-topology" 460 YANG modules of [RFC8346] (see section 3.1.1.1) 462 If, as discussed in section 3.2.2, IP Links created over DWDM can be 463 automatically discovered by the P-PNC, the IP Topology is needed 464 only to report these IP Links after being discovered by the P-PNC. 466 The IP Topology can also be used to configure the IP Links created 467 over DWDM. 469 3.2.2. IP Link Setup Procedure 471 The MDSC requires the O-PNC to setup a WDM Tunnel (either a WSON 472 Tunnel or a Flexi-grid Tunnel) within the DWDM network between the 473 two Optical Transponders (OTs) associated with the two access links. 475 The Optical Transponders are reported by the O-PNC as Trail 476 Termination Points (TTPs), defined in [TE-TOPO], within the WDM 477 Topology. The association between the Ethernet access link and the 478 WDM TTP is reported by the Inter-Layer Lock (ILL) identifiers, 479 defined in [TE-TOPO], reported by the O-PNC within the Ethernet 480 Topology and WDM Topology. 482 The MDSC also requires the O-PNC to steer the Ethernet client 483 traffic between the two access Ethernet Links over the WDM Tunnel. 485 After the WDM Tunnel has been setup and the client traffic steering 486 configured, the two IP routers can exchange Ethernet packets between 487 themselves, including LLDP messages. 489 If LLDP [IEEE 802.1AB] is used between the two routers, the P-PNC 490 can automatically discover the IP Link being setup by the MDSC. The 491 IP LTPs terminating this IP Link are supported by the ETH LTPs 492 terminating the two access links. 494 Otherwise, the MDSC needs to require the P-PNC to configure an IP 495 Link between the two routers: the MDSC also configures the two ETH 496 LTPs which support the two IP LTPs terminating this IP Link. 498 3.3. Provisioning of an IP link/LAG over DWDM with path constraints 500 MDSC must be able to provision an IP link with a fixed maximum 501 latency constraint, or with the minimum latency available constraint 502 within each domain but as well inter-domain when required (e.g. by 503 monitoring traffic KPIs trends for this IP link). Through the O-PNC 504 fixed latency path/minimum latency path is chosen between PE and 505 ASBR in each optical domain. Then MDSC needs to select the inter-AS 506 domain with less latency (in case we have several interconnection 507 links) to have the right low latency constraint fulfilled end-to-end 508 across domains. 510 MDSC must be able to automatically create two IP links between two 511 routers, over DWDM network, with physical path diversity (avoiding 512 SRLGs communicated by O-PNCs to the MDSC). 514 MDSC must be responsible to route each of this IP links through 515 different inter-AS domain links so that end-to-end IP links are 516 fully disjoint. 518 Optical connectivity must be set up accordingly by MDSC through O- 519 PNCs. 521 3.3.1. YANG models used at the MPIs 523 This is for further study 525 3.4. Provisioning of an additional link member to an existing LAG with 526 or without path constraints 528 For adding an additional link member to a LAG between two routers 529 with or without path latency/diversity constraint. MDSC must be able 530 to force additional optical connection to use the same physical path 531 in the optical domain where the LAG capacity increase is required. 533 3.4.1. YANG models used at the MPIs 535 This is for further study 537 4. Multi-Layer Recovery Coordination 539 4.1. Ensuring Network Resiliency during Maintenance Events 541 Before planned maintenance operation on DWDM network takes place, IP 542 traffic should be moved hitless to another link. 544 MDSC must reroute IP traffic before the events takes place. It 545 should be possible to lock IP traffic to the protection route until 546 the maintenance event is finished, unless a fault occurs on such 547 path. 549 4.2. Router port failure 551 The focus is on client-side protection scheme between IP router and 552 reconfigurable ROADM. Scenario here is to define only one port in 553 the routers and in the ROADM muxponder board at both ends as back-up 554 ports to recover any other port failure on client-side of the ROADM 555 (either on router port side or on muxponder side or on the link 556 between them). When client-side port failure occurs, alarms are 557 raised to MDSC by IP-PNC and O-PNC (port status down, LOS etc.). 558 MDSC checks with OP-PNC(s) that there is no optical failure in the 559 optical layer. 561 There can be two cases here: 563 a) LAG was defined between the two end routers. MDSC, after checking 564 that optical layer is fine between the two end ROADMs, triggers 565 the ROADM configuration so that the router back-up port with its 566 associated muxponder port can reuse the OCh that was already in 567 use previously by the failed router port and adds the new link to 568 the LAG on the failure side. 570 While the ROADM reconfiguration takes place, IP/MPLS traffic is 571 using the reduced bandwidth of the IP link bundle, discarding 572 lower priority traffic if required. Once backup port has been 573 reconfigured to reuse the existing OCh and new link has been 574 added to the LAG then original Bandwidth is recovered between the 575 end routers. 577 Note: in this LAG scenario let assume that BFD is running at LAG 578 level so that there is nothing triggered at MPLS level when one 579 of the link member of the LAG fails. 581 b) If there is no LAG then the scenario is not clear since a router 582 port failure would automatically trigger (through BFD failure) 583 first a sub-50ms protection at MPLS level :FRR (MPLS RSVP-TE 584 case) or TI-LFA (MPLS based SR-TE case) through a protection 585 port. At the same time MDSC, after checking that optical network 586 connection is still fine, would trigger the reconfiguration of 587 the back-up port of the router and of the ROADM muxponder to re- 588 use the same OCh as the one used originally for the failed router 589 port. Once everything has been correctly configured, MDSC Global 590 PCE could suggest to the operator to trigger a possible re- 591 optimisation of the back-up MPLS path to go back to the MPLS 592 primary path through the back-up port of the router and the 593 original OCh if overall cost, latency etc. is improved. However, 594 in this scenario, there is a need for protection port PLUS back- 595 up port in the router which does not lead to clear port savings. 597 5. Security Considerations 599 Several security considerations have been identified and will be 600 discussed in future versions of this document. 602 6. Operational Considerations 604 Telemetry data, such as the collection of lower-layer networking 605 health and consideration of network and service performance from POI 606 domain controllers, may be required. These requirements and 607 capabilities will be discussed in future versions of this document. 609 7. IANA Considerations 611 This document requires no IANA actions. 613 8. References 615 8.1. Normative References 617 [RFC7950] Bjorklund, M. et al., "The YANG 1.1 Data Modeling 618 Language", RFC 7950, August 2016. 620 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 621 7951, August 2016. 623 [RFC8040] Bierman, A. et al., "RESTCONF Protocol", RFC 8040, January 624 2017. 626 [RFC8345] Clemm, A., Medved, J. et al., "A Yang Data Model for 627 Network Topologies", RFC8345, March 2018. 629 [RFC8346] Clemm, A. et al., "A YANG Data Model for Layer 3 630 Topologies", RFC8346, March 2018. 632 [RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction 633 and Control of TE Networks (ACTN)", RFC8453, August 2018. 635 [RFC8525] Bierman, A. et al., "YANG Library", RFC 8525, March 2019. 637 [IEEE 802.1AB] IEEE 802.1AB-2016, "IEEE Standard for Local and 638 metropolitan area networks - Station and Media Access 639 Control Connectivity Discovery", March 2016. 641 [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", 642 draft-ietf-teas-yang-te-topo, work in progress. 644 [WSON-TOPO] Lee, Y. et al., " A YANG Data Model for WSON (Wavelength 645 Switched Optical Networks)", draft-ietf-ccamp-wson-yang, 646 work in progress. 648 [Flexi-TOPO] Lopez de Vergara, J. E. et al., "YANG data model for 649 Flexi-Grid Optical Networks", draft-ietf-ccamp-flexigrid- 650 yang, work in progress. 652 [CLIENT-TOPO] Zheng, H. et al., "A YANG Data Model for Client-layer 653 Topology", draft-zheng-ccamp-client-topo-yang, work in 654 progress. 656 [TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic 657 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 658 te, work in progress. 660 [WSON-TUNNEL] Lee, Y. et al., "A Yang Data Model for WSON Tunnel", 661 draft-ietf-ccamp-wson-tunnel-model, work in progress. 663 [Flexi-MC] Lopez de Vergara, J. E. et al., "YANG data model for 664 Flexi-Grid media-channels", draft-ietf-ccamp-flexigrid- 665 media-channel-yang, work in progress. 667 [CLIENT-SIGNAL] Zheng, H. et al., "A YANG Data Model for Transport 668 Network Client Signals", draft-ietf-ccamp-client-signal- 669 yang, work in progress. 671 8.2. Informative References 673 [TNBI] Busi, I., Daniel, K. et al., "Transport Northbound 674 Interface Applicability Statement", draft-ietf-ccamp- 675 transport-nbi-app-statement, work in progress. 677 [ACTN-VPN] Lee, Y. et al., " Applicability of ACTN to Support 678 Packet and Optical Integration", draft-lee-teas-actn-poi- 679 applicability, work in progress. 681 9. Acknowledgments 683 This document was prepared using 2-Word-v2.0.template.dot. 685 Some of this analysis work was supported in part by the European 686 Commission funded H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727). 688 10. Authors' Addresses 690 Fabio Peruzzini 691 TIM 693 Email: fabio.peruzzini@telecomitalia.it 695 Italo Busi 696 Huawei 698 Email: Italo.busi@huawei.com 699 Daniel King 700 Old Dog Consulting 702 Email: daniel@olddog.co.uk 704 Sergio Belotti 705 Nokia 707 Email: sergio.belotti@nokia.com 709 Gabriele Galimberti 710 Cisco 712 Email: ggalimbe@cisco.com 714 Zheng Yanlei 715 China Unicom 717 Email: zhengyanlei@chinaunicom.cn 719 Washington Costa Pereira Correia 720 TIM Brasil 722 Email: wcorreia@timbrasil.com.br 724 Jean-Francois Bouquier 725 Vodafone 727 Email: jeff.bouquier@vodafone.com