Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) for Packet Optical Integration (POI) service assurance

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."¶

This Internet-Draft will expire on 18 March 2024.¶

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

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.¶

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

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.¶

                              +----------+
                              |   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       /
       \                          /   \                            /
        +------------------------+     +--------------------------+

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.¶

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.¶
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]¶

5. Optical Network Failure and Performance Degradation

6. Failures between the IP and Optical edges

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.¶

Acknowledgments

TODO acknowledge.¶

Authors' Addresses