TEAS WG I. Busi Internet-Draft Huawei Technologies Intended status: Informational J.-F. Bouquier Expires: 14 September 2023 Vodafone F. Peruzzini TIM P. Volpato Huawei Technologies P. Manna Cisco 13 March 2023 Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) for Packet Optical Integration (POI) service assurance draft-poidt-teas-actn-poi-assurance-00 Abstract This document extends the analysis of the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI), provided in RFC YYYY, to cover multi-layer service assurance scenarios, for end-to-end customer L2VPN or L3VPN connectivity services setup over underlying transport optical paths, with specific Service Level Agreement (SLA) requirements. EDITORS NOTE: Replace RFC YYYY with the RFC number of draft-ietf- teas-actn-poi-applicability once it has been published. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) service assurance scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface) in the ACTN architecture. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Busi, et al. Expires 14 September 2023 [Page 1] Internet-Draft ACTN POI Assurance March 2023 This Internet-Draft will expire on 14 September 2023. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. Reference Network Architecture . . . . . . . . . . . . . . . 3 4. YANG Data Models for the MPIs . . . . . . . . . . . . . . . . 6 5. Optical Network Failure and Performance Degradation . . . . . 7 5.1. Fault Detection . . . . . . . . . . . . . . . . . . . . . 7 5.2. Performance Monitoring . . . . . . . . . . . . . . . . . 7 5.3. Protection Switching . . . . . . . . . . . . . . . . . . 7 5.4. Maintenance . . . . . . . . . . . . . . . . . . . . . . . 7 6. Failures between the IP and Optical edges . . . . . . . . . . 7 6.1. Fault Detection . . . . . . . . . . . . . . . . . . . . . 8 6.2. Protection Switching . . . . . . . . . . . . . . . . . . 8 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction TODO Complete the Introduction Multi-layer and multi-domain service assurance scenarios, based on the reference network described in section 2 of [I-D.ietf-teas-actn-poi-applicability] and very relevant for Service Providers, are described in sections Section 5 and Section 6. Busi, et al. Expires 14 September 2023 [Page 2] Internet-Draft ACTN POI Assurance March 2023 This document is focusing on service assurance for end-to-end L2VPN or L3VPN connectivity services setup over underlying transport optical paths that requires multi-layer coordination For each scenario, existing IETF YANG data models, identified in section Section 4, are analyzed with a particular focus on the MPI in the ACTN architecture. For each multi-layer scenario, the document analyzes how to use the interfaces and data models of the ACTN architecture. A summary of the gaps identified in this analysis is provided in Section 7. Understanding the level of standardization and the possible gaps will help assess the feasibility of integration between packet and optical DWDM domains (and optionally OTN layer) from an end-to-end multi- vendor service assurance perspective. 2. Conventions and Definitions 2.1. Terminology TODO Terminology 3. Reference Network Architecture This document analyses several scenarios for service assurance in Packet and Optical Integration (POI) in which ACTN hierarchy is deployed to control a multi-layer and multi-domain network with two optical domains and two packet domains, as shown in Figure 1 of [I-D.ietf-teas-actn-poi-applicability], which is copied in Figure 1 below. Busi, et al. Expires 14 September 2023 [Page 3] Internet-Draft ACTN POI Assurance March 2023 +----------+ | MDSC | +-----+----+ | +-----------+-----+------+-----------+ | | | | +----+----+ +----+----+ +----+----+ +----+----+ | P-PNC 1 | | O-PNC 1 | | O-PNC 2 | | P-PNC 2 | +----+----+ +----+----+ +----+----+ +----+----+ | | | | | \ / | +-------------------+ \ / +-------------------+ CE1 / PE1 BR1 \ | / / BR2 PE2 \ CE2 o--/---o o---\-|-------|--/---o o---\--o \ : : / | | \ : : / \ : PKT domain 1 : / | | \ : PKT domain 2 : / +-:---------------:-+ | | +-:---------------:--+ : : | | : : : : | | : : +-:---------------:------+ +-------:---------------:--+ / : : \ / : : \ / o...............o \ / o...............o \ \ optical domain 1 / \ optical domain 2 / \ / \ / +------------------------+ +--------------------------+ Figure 1: Reference Network (copy of Figure 1 of RFC YYYY) EDITORS NOTE: Replace RFC YYYY with the RFC number of [I-D.ietf-teas-actn-poi-applicability] once it has been published. In general, service assurance involves fault detection and localization; performance monitoring as well as re-routing (protection). Two cases will be considered: 1. using grey interfaces on routers' ports, as outlined in [I-D.ietf-teas-actn-poi-applicability] 2. using colored optical interfaces on routers' ports, as outlined in [I-D.mix-teas-actn-poi-extension] NOTE: It is not fully clear how much commonalities there are in service assurance for these two cases. This draft will start addressing both cases. At a later stage it will be assessed whether it is worthwhile keeping everything in a single draft or to split into two drafts. Busi, et al. Expires 14 September 2023 [Page 4] Internet-Draft ACTN POI Assurance March 2023 The MDSC is responsible for coordinating the whole multi-domain, multi-layer (packet and optical) network. MDSC interacts with different Provisioning Network Controllers (O/P-PNCs) through the MPI interface. The MPI interface presents an abstracted topology to MDSC, hiding the technology-specific aspects of the network and the topology details (depending on the policy chosen regarding the level of abstraction supported). Following the assumptions of section 2.1.2 of [I-D.ietf-teas-actn-poi-applicability], this document analyses scenarios where the MDSC uses the partial summarization approach to coordinate multi-domain/multi-layer path computation. In this approach, the MDSC has complete visibility of the TE topology of the packet network domains and an abstracted view of the TE topology of the optical network domains. That means the MDSC has the capability of performing multi-domain/single-layer path computation for the packet layer. The MDSC needs to delegate the O-PNCs to perform local path computation within their respective domains. It uses the information received by the O-PNCs and its TE topology view of the multi-domain packet layer to perform multi-layer/multi-domain path computation. P-PNCs are responsible for setting up the TE paths between any two PEs or BRs in their respective controlled domains, as requested by MDSC, and providing topology information to the MDSC. O-PNCs are responsible to provide to the MDSC an abstract TE topology view of their underlying optical network resources. They perform single-domain local path computation, when requested by the MDSC. They also perform optical tunnel setup, when requested by the MDSC. No GMPLS-UNI interaction between IP and Optical equipment is considered. This is also the assumption followed in this document: the MDSC performs the function of multi-layer/multi-domain path computation through the same mechanisms described in [I-D.ietf-teas-actn-poi-applicability]. TO DO - Complete the description of the pre-requisites of MDSC in the cases discussed. The following list summarizes the main assumptions about how MDSC can handle the service assurance cases described in this document. Most of them have been already described in [I-D.ietf-teas-actn-poi-applicability] 1. MDSC has acquired all the topology and status information of both the IP and optical layers. Busi, et al. Expires 14 September 2023 [Page 5] Internet-Draft ACTN POI Assurance March 2023 2. MDSC is fully aware of any multi-layer connections between the IP and the optical layers. It is also aware of the multi-domain interconnection links between different IP domains. 3. MDSC is aware of any topology or resource utilization change obtained in real time through coordination with the O/P-PNCs. This applies in the case of a fault or a maintenance activity involving either the IP or the DWDM layer. 4. MDSC coordinates the IP and DWDM protections and, as a result, the re-routing of traffic at both the IP and DWDM layer. 5. Before planned maintenance operation at the DWDM layer, MDSC instructs the P-PNC to move the affected IP traffic to an other link in an hitless way. This is done before the event takes place. MDSC also coordinates with P-PNC to revert back the traffic on the original path when the maintenance event is concluded. 6. When the O-PNC detects a degradation of optical performance (e.g. BER PRE-FEC values threshold crossing over a certain period of time), it alerts the MDSC so that the MDSC relates the warning to an IP link. 7. MDSC distinguishes between IP and Optical failures. For example, in the case of the failure of an IP port of a router, the IP traffic may be switched to a stand-by port, reusing the same ROADM optical resources (lambda, optical path) and keeping the end-to-end IP connection. If a remote IP node fails, then a re- route of optical resources takes place together with a switch of the local IP port in order to establish a new connection with a different IP node used for protection. 4. YANG Data Models for the MPIs TODO YANG Data Models Initial set of YANG models that are potentially in the scope of this analysis: * ietf-alarms defined in [RFC8632] * ietf-performance-monitoring defined in [I-D.yu-performance-monitoring-yang] Busi, et al. Expires 14 September 2023 [Page 6] Internet-Draft ACTN POI Assurance March 2023 5. Optical Network Failure and Performance Degradation 5.1. Fault Detection TODO Describe fault detection performed by the O-PNC and how this information is reported to the MDSC: see for example the failure scenario in https://github.com/italobusi/draft-poidt-teas-actn-poi- assurance/files/10885907/2023.03.draft-poidt-teas-poi-assurance.pptx (slide 3) 5.2. Performance Monitoring TODO Describe performance monitoring and performance degradation detection performed by the O-PNC and how this information is reported to the MDSC: see for example the degradation scenario in https://github.com/italobusi/draft-poidt-teas-actn-poi-assurance/ files/10885907/2023.03.draft-poidt-teas-poi-assurance.pptx (slide 7) 5.3. Protection Switching Failures in the optical domain can be recovered by packet-based protection mechanisms as described in [I-D.ietf-teas-actn-poi-applicability]. TODO Describe how the MDSC coordinates the protection switching mechanisms at the IP layer (e.g., FRR) and at optical layer, including the reversion when the failure is repaired: see for example the protection switching scenario in https://github.com/italobusi/ draft-poidt-teas-actn-poi-assurance/files/10885907/2023.03.draft- poidt-teas-poi-assurance.pptx (slide 3) 5.4. Maintenance TODO Describe how the MDSC initiates protection switching at the IP layer (e.g., FRR) and at optical layer at the beginning of a maintenance window, including the reversion after the maintenance operations are completed: see for example the maintenance scenario in https://github.com/italobusi/draft-poidt-teas-actn-poi-assurance/ files/10885907/2023.03.draft-poidt-teas-poi-assurance.pptx (slide 4) 6. Failures between the IP and Optical edges Busi, et al. Expires 14 September 2023 [Page 7] Internet-Draft ACTN POI Assurance March 2023 6.1. Fault Detection TODO Describe the mechanisms to detect when the failure occurs on a router port or on the router node connected with the optical domain: see for example the fault scenarios in https://github.com/italobusi/ draft-poidt-teas-actn-poi-assurance/files/10885907/2023.03.draft- poidt-teas-poi-assurance.pptx (slide 5 and slide 6) 6.2. Protection Switching TODO Describe the mechanisms to protect the traffic when the failure occurs on a router port or on the router node connected with the optical domain: see for example the protection scenarios in https://github.com/italobusi/draft-poidt-teas-actn-poi-assurance/ files/10885907/2023.03.draft-poidt-teas-poi-assurance.pptx (slide 5 and slide 6) 7. Conclusions This section will provide a summary of the analysis and of the gaps identified in this draft once the analysis is mature. 8. Security Considerations TODO Security 9. IANA Considerations This document has no IANA actions. 10. References 10.1. Normative References [I-D.ietf-teas-actn-poi-applicability] Peruzzini, F., Bouquier, J., Busi, I., King, D., and D. Ceccarelli, "Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI)", Work in Progress, Internet-Draft, draft-ietf-teas-actn-poi-applicability-08, 11 January 2023, . Busi, et al. Expires 14 September 2023 [Page 8] Internet-Draft ACTN POI Assurance March 2023 [I-D.yu-performance-monitoring-yang] Yu, C., "A YANG Data Model for Optical Performance Monitoring", Work in Progress, Internet-Draft, draft-yu- performance-monitoring-yang-00, 24 October 2022, . [RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm Management", RFC 8632, DOI 10.17487/RFC8632, September 2019, . 10.2. Informative References [I-D.mix-teas-actn-poi-extension] Galimberti, G., Bouquier, J., Gerstel, O., Foster, B., and D. Ceccarelli, "Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) extensions to support Router Optical interfaces.", Work in Progress, Internet-Draft, draft-mix- teas-actn-poi-extension-00, 24 October 2022, . Acknowledgments TODO acknowledge. Authors' Addresses Italo Busi Huawei Technologies Email: italo.busi@huawei.com Jean-Francois Bouquier Vodafone Email: jeff.bouquier@vodafone.com Fabio Peruzzini TIM Email: fabio.peruzzini@telecomitalia.it Paolo Volpato Huawei Technologies Email: paolo.volpato@huawei.com Busi, et al. Expires 14 September 2023 [Page 9] Internet-Draft ACTN POI Assurance March 2023 Prasenjit Manna Cisco Email: prmanna@cisco.com Busi, et al. Expires 14 September 2023 [Page 10]