**Session Date/Time:** 16 Feb 2022 13:00

# [CCAMP](../wg/ccamp.html)

## Summary

This interim meeting of the CCAMP Working Group focused on the recently adopted draft "Framework and Data Model for OTN Network Slicing". The discussion revolved around the necessity and conceptual validity of OTN slicing, its relationship with the broader IETF Network Slice Framework, and its interaction with existing transport technologies. Significant debate occurred regarding the scope of "slicing" (5G-only vs. generalized, IP-only vs. multi-layer transport) and the appropriate terminology. The working group decided to consolidate questions for the TEAS WG to clarify the fundamental concepts of network slicing.

## Key Discussion Points

*   **Draft Adoption and Comments Overview**:
    *   The "Framework and Data Model for OTN Network Slicing" draft was recently adopted by the working group.
    *   A significant number of comments were received during adoption, now tracked in GitHub.
    *   Authors categorized comments into four areas:
        1.  **Draft Text Improvements**: Authors are working on incorporating these into the next draft update.
        2.  **Harmonization with Existing Models**:
            *   **IETF Network Slicing Yang**: Consensus for the OTN slicing model to augment `ietf-network-slicing.yang`.
            *   **T-SDN Applicability**: Clarifications/updates needed in T-SDN slicing draft pictures to align with OTN and network slicing concepts.
        3.  **TEAS-addressable Questions**: Several comments were deemed to be generic to the IETF Network Slice Framework itself and should be addressed by TEAS (e.g., "slice" vs. "resource partitioning", use of existing models like T-Topology/VM for configuration, perceived prematurity of the network slice framework).
        4.  **OTN-specific Questions**: Two core questions remained for CCAMP: "Do we really need slicing for OTN?" and "Can we call it slicing for OTN?".

*   **Discussion on "Do we need slicing for OTN?"**:
    *   **Authors' Position (Yes)**:
        *   **Use Cases**: Identified use cases for OTN-only networks (no IP) and IP over optical, including network code sharing, wholesaling, private OTN interconnects, and end-to-end network slicing where OTN is a component.
        *   **Industry Practice**: Many optical vendors already deploy or offer commercial applications resembling OTN slices, often with proprietary interfaces, highlighting the need for standardization.
        *   **Scope**: Slicing for OTN is considered within the scope defined by the IETF Network Slice Framework.
    *   **Intent vs. Realization**:
        *   **Intent**: An OTN slice is presented as an *intent* – a high-level expression of customer needs (topology, connections, measurable SLOs/SLES).
        *   **Realization**: The realization of an OTN slice leverages existing IETF technologies (e.g., L1 VPN, T-Topology, T-Tunnels, NMS/NETCONF/YANG for cross-connects).
        *   **Data Plane**: OTN's time slot-based data plane supports "hard slicing", simplifying realization but still requiring intent-based MBI models for northbound interfaces.
        *   **OTN-specific SLOs**: The concept of slicing for OTN requires defining technology-specific SLOs like Bit Error Rate (BER) or frame jitter, and reinterpreting generic SLOs like bandwidth and availability at the ODU layer.
    *   **Slice Configuration Scenarios**: Three main scenarios were presented:
        1.  **OTN-only Network**: An OTN Slice Controller (OTN-SC) interfaces with an OTN-aware consumer using an OTN-slice NBI to configure an OTN-only slice.
        2.  **IP + OTN (Direct)**: An IETF Network Slice Controller (IETF-NSC) directly interacts with IP and OTN domains (via existing southbound interfaces like PNC MBI) to realize a cross-layer slice.
        3.  **IP + OTN (Delegated)**: An IETF-NSC delegates the OTN portion of an end-to-end slice to an OTN-SC, using an "intent-like" OTN-slice NBI.
    *   **Igor's Concerns**:
        *   **Concept of Slicing**: Argued that "network slicing" is an inherently top-down, emergent, dynamic process focused on supporting SLOs, while OTN is a transport layer that provides bottom-up, point-to-point connectivity.
        *   **Point-to-Multipoint (P2MP)**: Questioned the feasibility and actual operator use of P2MP/MP2MP services in OTN as part of slicing, asserting OTN is limited to point-to-point links for higher layers.
        *   **5G Scope**: Challenged the claim that the IETF Network Slice Framework is not limited to 5G, stating that all definitions and requirements within it are derived from 5G, and OTN has no unique role in 5G beyond traditional transport.
        *   **Slippery Slope**: Expressed concern that approving OTN slicing would necessitate similar work for all other transport layers (microwave, OCH, FlexE), akin to repeating prior work on T-Tunnels and Topologies under a new "slicing" label.
    *   **Authors' Responses**:
        *   Acknowledged that existing technologies realize slices, but an intent-like interface for OTN is still needed.
        *   Confirmed that OTN data plane supports point-to-point and point-to-multipoint, with MP-to-MP not directly supported. Operators choose which service types and SLOs to offer.
        *   Reiterated that the IETF Network Slice Framework explicitly states it's "not limited to 5G" and includes other use cases (e.g., in the framework's first paragraph). This point led to significant debate, with the Chairs suggesting it's a fundamental question for TEAS.
        *   Maintained that OTN *can* transport 5G services (e.g., for low latency, high quality) as part of the transport segment within a 5G slice, whether it's OTN-only, IP over OTN, or a hybrid.
        *   Clarified that the IETF Network Slice Framework supports non-IP endpoints, making OTN a valid candidate.
    *   **Relationship between IETF-NSC and OTN-SC (Sai's Concerns)**:
        *   The figure seemed to depict OTN-SC as entirely independent from IETF-NSC, suggesting it would be rebuilt separately.
        *   Proposed that OTN-SC should be viewed as an *augmentation* or *instantiation* of an IETF-NSC, understanding OTN-specific parameters, rather than a separate, unrelated entity.
        *   Authors agreed that the figure shows functional blocks, which in implementation could be embedded within a single controller; an OTN slice is essentially an IETF network slice with OTN augments.

*   **Discussion on "Can we call it an OTN Slice?"**:
    *   **Authors' Position (Yes)**:
        *   The TEAS WG has a consensus to redefine "slicing" beyond 5G and purely IP scenarios.
        *   OTN networks can have non-IP endpoints (e.g., for video or wholesale services).
        *   By defining "OTN slice" as an "IETF network slice where the network is OTN" and operating within the IETF Network Slice Framework, ambiguity can be avoided.
    *   **Relationship to L1 VPN**: An OTN slice is an *intent*, while an L1 VPN is a *possible realization* of that intent (among others). This relationship is analogous to how an IETF network slice relates to L1/L2/L3 VPNs.

## Decisions and Action Items

*   **Decision**: The working group will continue to discuss the fundamental questions regarding the scope and definitions of network slicing on the CCAMP mailing list.
*   **Action Item (Chairs, WG Participants)**: Formulate a consolidated set of questions, with precise wording, on the CCAMP mailing list. These questions will address the scope of the IETF Network Slice Framework (e.g., 5G-only vs. broader, IP-only vs. multi-layer transport, the definition of "slice") and will be sent as a liaison statement to the TEAS Working Group once consensus is reached on the questions themselves.
*   **Action Item (Authors)**:
    *   Update the draft text and the data model.
    *   Ensure alignment between the IETF Network Slice NBI and the OTN model.
    *   Clarify and define technology-specific SLOs relevant to OTN slicing within the draft.
    *   Continue hosting weekly discussions on OTN slicing.

## Next Steps

*   Continued discussion on the CCAMP mailing list to refine questions for TEAS.
*   Drafting of a liaison statement to TEAS for clarification on the IETF Network Slice Framework's scope and definitions.
*   Authors to update the OTN Network Slicing draft based on comments and discussions, particularly regarding alignment and SLO definitions.
*   Weekly discussions on OTN slicing will continue.