Security and Operational concerns in ACTN POI work

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.

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 when, and only when, they appear in all capitals, as shown here.

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.

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

Combine [ACTNPOI] and [DavisPPCA]
Include an Operational Considerations section in the new combined draft that addresses the matters raised herein.
Include appropriate matters raised herein in the mandatory Security section
Liaise to TIP, ONF and SG15 soliciting comment on the issues raised herein.
Include management of smart plugs in the scope of this work. [We will provide a draft on this topic].
Liaise to OIF CCAMP's interest in management of smart plugs topic and ask for access to early drafts of that work.

IANA Considerations This memo includes no request to IANA.

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.

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.