Internet-Draft SAOC-IN-ACTN-POI October 2023
Doolan & Bock Expires 25 April 2024 [Page]
CCAMP Working Group
Intended Status:
P. J. Doolan
H. Bock

Security and Operational concerns in ACTN POI work


Work in CCAMP on POI in ACTN is at an early stage and does not yet seem to have adequately described some of the operational or security concerns which may impact the real world applicability of any resulting work product

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

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 25 April 2024.

Table of Contents

1. Introduction

CCAMP is actively considering two Internet Drafts [ACTNPOI][DavisPPCA] which target the same problem space. For the purpose this brief draft we describe that problem space as automation of the managment of networks composed of combined packet and optical networking components; more simply management of the IPoDWM concept that is currently enjoying a renaissance in interest. We say renaissance because this current work is not the first to address the topic, as far back as 2015 the BBF wrote a technical report [TR319] on the subject.

[ACTNPOI] focuses on Traffic Engineered services supported by the Abstraction and Control of TE Networks (ACTN) architecture, in contrast [DavisPPCA] focuses more on the availability of pluggable coherent optical modules and the control architecture needed to support them. Both IDs describe SDN enabled solutions to the automation problem. Early on in [ACTNPOI] the authors describe a key aspect of the PMO of these networks: " In many existing network deployments, the packet and the optical networks are engineered and operated independently" . We believe that to be the most important insight about this problem space and one we feel has not been adequately emphasised in these works so far and has received similar lack of serious attention in other SDO's and Fora.

The relentless progress that has led to the availability of Small Form Factor pluggable optics which motivate both these drafts continues. As a result we are seeing the emergence of what for want of a better term are being called 'smart plugs'. Such devices are already being deployed and we believe this work CCAMP is progressing should acknowledge this and consider applicability of this work to the automation of management of them as well. We note for information that the OIF [OIF] has project to develop a white paper on the management of smart plugs which they intend to publish in 2024.

All ID's are required to have a Security Considerations section and we note that both drafts do but neither address matters we believe to be of conern. ID's are not required to contain an Operational Considerations section, [ACTNPOI] does but it is brief and does not address matters we believe to be of concern. It could be argued that the use cases in [DavisPPCA] essentially constitute operational considerations but again we do not believe they sufficiently address the matters of concern to us.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Discussion

The resurgence of interest in IPoDWDM enabled by pluggable optical modules means it is being discussed in TIP, ONF, ITU, IETF. Recent discussions with a number of industry participants have indicated to us that there’s a problem with the solutions proposed in these two drafts, indeed perhaps with SDN in general: the benefits of automated management espoused in these drafts are unattainable, or at risk, because of PMO in some of the intended user community.

We could say “OK that’s the way it is, it’s not our problem, there’s nothing we can do about it”. That, to us, seems short sighted. At the very least we believe that Informational RCFs should expose the potential problem and beyond that we believe they might point at a solution; we do not believe the problem to be insoluble but we concede we are still exploring it and anticipate further contributions as our understanding develops

The separate engineering and operation of packet and optical networks that together provide a service for an operator or its customers are, reasonably we believe, claimed to cause inefficiences that lead to higher opex than might be otherwise incurred and this is one of the motivations behind much of the SDN work of the last decade. Combined control of the two infrastructures is viewed as less costly. The authors of this draft subscribe to the view that sufficient architectural and protocol work has occured over the last decade or so, to claim that combined control should be possible from a technical perspective. We have recently begun to hear rumblings in multiple venues, of operational and security concerns that question the operationalization of solutions based on that work..

Our industry is discussing a small number of different approaches for control of DWDM optical interfaces which differ specifically with respect to which entity is allowed to control setting parameters for those interfaces. One approach, described by TIP [TIP] MANTRA in their whitepaper [MANTRA] and in [ACTNPOI], only allows write access to equipment hosting pluggables from one single SDN control entity – which they call the IP or L3 controller. While they do consider the option to allow read-only access from a DWDM SDN controller to that host equipment, this means that both IP controller and host SW play a role in setting DWDM physical layer parameters. While this creates clarity on the ownership of the parameters and means that all aspects of security (e.g. authentication, user management, …) remain unchanged for the host to IP controller interaction, it does mean that host SW, IP controller SW and DWDM control entities as well as pluggable firmware are all coupled together. This jeopardizes that benefit network operators are looking for in disaggregated, open networking which is fast, decoupled innovation in different network functions(hardware and software).

[Borraccini] and [DavisPPCA] add an additional option that separates DWDM control aspects from packet control by partitioning the write access via control API into packet layer and DWDM layer functions. This decouples controller SW releases between the two layers. While it simplifies introduction of new features, simplifies the interaction between pluggables and DWDM / OLS control it also means that operationally, the additional control SW has to be accepted by ops teams, in addition host SW still remains coupled to pluggable feature evolution.

Additional approaches under discussion involve an even more fundamental separation of control aspects by host independent management e.g. the whitepaper under development in OIF. Direct access from DWDM control SW to pluggables’ DWDM functions would completely decouple SW evolution between the layers and greatly simplify technology evolution over time. While this new approach shows great promise, it’s operational aspects still need to be clarified.

We believe that an Informational RFC on POI should describe and investigate these approaches more fully than the current drafts do at this stage. We further think an Informational draft is an appropriate vehicle to advocate for solutions that offer the maximum flexibility, i.e. solutions that do not preclude operational choices that the operators business structure or practices may otherwise be able to exploit. Stated differently it should provide a framework that describes the small number of important operational models that are distinguishablel in this problem space. Based on that belief and the forgoing discussion we offer proposals as follow.

3. Proposals

We respectfully request that CCAMP consider the actions listed below as a result of discussion of this draft.

4. IANA Considerations

This memo includes no request to IANA.

5. Operational Considerations

This document indicates where operational and business concerns may be in conflict with security policy and render viable technical solutions impotent to automate the integrated management of combined packet and optical network.

6. Security Considerations

This document indicates where security concerns may conflict with or impact operational and business desires to automate the combined management of combined packet and optical network.

7. References

7.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.

7.2. Informative References

Davis, et al, N., "ID: Control Architecture of Optical Pluggables in Packet Devices Under ACTN POI Framework", .
Peruzzini, et al, F., "ID: Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI)", .
Broadband Forum, BBF., "Achieving Packet Network Optimization using DWDM Interfaces - Physically Separated Model", , <>.
Borraccini, et al, G., "QoT-Driven Optical Control and Data Plane in Multi-Vendor Disaggregated Networks, M4F.5, OFC 2022", .
TIP, "IPoWDM convergent SDN architecture - Motivation, technical definition & challenges", , <>.
TIP, "Telecom Infra Project", , <>.
OIF, "Optical Internetworking Forum", , <>.

Authors' Addresses

P. Doolan
United States of America
H. Bock