teas

Summary

The teas working group session at IETF 112 covered an update on the general status of working group documents, including several drafts nearing Last Call. Detailed presentations and discussions focused on updates to the ietf-te-vpn, ietf-te-telemetry, and ietf-te-service-mapping Yang models. A significant portion of the session was dedicated to a technical discussion on the different types of connectivity matrices defined in the ietf-te-framework document, prompting questions about terminology, scope, and the relationship between service abstraction and network realization.

Key Discussion Points

Working Group Status Updates (Pawan Biram):
- General: No new RFCs, but a batch of documents are moving towards Working Group Last Call. One document (signaling extensions for some pivot) is in the publication request queue. One new document adoption.
- ietf-enhanced-vpn-framework: A new revision was published detailing applicability to network slicing. The chairs noted that Enhanced VPN offers one solution approach for IETF network slices but is not the sole approach. Authors are encouraged to use the mailing list or open discussion time to clarify the relationship with IETF network slices.
- ietf-pcc-use-cases: The chairs decided to move this document to Working Group Last Call. Authors are completing pending items, and working group review is requested.
- rfc3272bis: A new revision was published. An open question remains on whether to change the scope from "Overview and Principles of Internet Traffic Engineering" to "Overview and Principles of Traffic Engineering." Further input and reviews are requested due to a lack of previous discussion.
- ietf-sf-aware-topology-yang: Authors requested a Yang Doctors review, which has been initiated.
- ietf-te-base-yang: Authors requested Working Group Last Call. The plan is to proceed with this document first, with the RSVP and MPLS Yang documents to follow. IPR disclosure for this document has begun.
- Administrative: A reminder was given for co-authors to verify email addresses, as one author's email was bouncing.
ietf-te-vpn Yang Model Updates (Dhruv Dhody):
- This model describes the customer's view of a virtual network, abstracting TE topology and tunnel models.
- Updates: Cleaned up naming conventions, added an empty underlay container for future augmentations (e.g., SR policy details), refined the vn-compute-status description, included cos (Class of Service, reusing te-types dst-class-type) as an additional constraint, and updated JSON examples.
- Discussion: The cos constraint needs more descriptive text in the document. The approach of using an empty container for future extensibility requires further working group review.
ietf-te-telemetry Yang Model Updates (Dhruv Dhody):
- This model focuses on performance monitoring parameters and scaling intent mechanisms for VN/TE.
- Updates: Term "kpi" was removed for simplicity, figures depicting model relationships were clarified, an XML example for scaling was added, the term "proactive" was removed from re-optimization discussions, and security considerations were updated. Linkage with OPS area VPN service performance measurement work was also clarified.
- Discussion: It was noted that the Yang Doctors review process, which includes ADs from the OPS area, would address any terminology overlaps regarding "intent." The model specifically covers transport (TE/VN) telemetry, not service telemetry.
ietf-te-service-mapping Yang Model Updates (Dhruv Dhody):
- This model maps various services (L3SM, L2SM, L1CSM) and network models to TE infrastructure (topology, tunnel, VN).
- Updates: Clarified the purpose and usage scenarios (e.g., external vs. internal network use). Explicitly stated that scheduling and traffic mapping are out of scope for this document.
- Discussion:
  - IETF Network Slice: The working group chairs suggested keeping IETF network slice mapping out of scope for this document to avoid delays and allow it to be addressed through a future augmentation if needed. The authors will discuss this internally.
  - "Out of Scope" Statements: A concern was raised by the chair about explicitly stating items as "out of scope," as this could inadvertently hinder future augmentations. It was suggested that documents often remain silent on topics outside their scope unless there's a strong reason to explicitly exclude them. This will be discussed further on the mailing list.
ietf-te-framework Connectivity Matrix (Adrian Farrel):
- Revision 05 of the framework attempts to resolve open issues concerning connectivity matrices.
- Updates: Clarified definitions for Point-to-Point (P2P), Bi-directional P2P, Point-to-Multipoint (P2MP), and Multipoint-to-Point (MP2P). A new Any-to-Any (A2A) matrix was added to support various operator use cases, including VPN-type services, which behave as a rootable full mesh rather than traditional tunnels.
- Discussion:
  - Terminology: Discussion ensued on the definition of "connectivity matrix" and "connections," with calls for alignment with the te-topology model or explicit divergence.
  - Grouping: A suggestion was made to treat P2P and P2MP as fundamental types and categorize others (like hub-and-spoke or MP2MP) as groupings or derivations, rather than distinct matrix types.
  - Bi-directional P2P: It was generally agreed that bi-directional P2P remains an important service to call out separately.
  - SLOs/SLEs: Questions arose about the implicit derivation of receiver SLOs/SLEs from senders, and whether receivers should be able to define their own.
  - Multi-homing: The concept of multi-homing (multiple CEs for a receiver) was introduced as a factor that further complicates SLO definitions.
  - CE Definition: The definition of "Customer Endpoint (CE)" was questioned, particularly in contexts where it might refer to a service delivery point within the network or a Provider Edge (PE) device, highlighting a need for clearer scope.

Decisions and Action Items

Decision: The ietf-pcc-use-cases document will proceed to Working Group Last Call soon.
Decision: The ietf-te-base-yang document will proceed to Working Group Last Call first, with other RSVP and MPLS Yang documents to follow.
Action Item: Dhruv Dhody to add more descriptive text for the cos constraint in the ietf-te-vpn Yang model.
Action Item: Dhruv Dhody to discuss with co-authors and the working group (on the mailing list) regarding the inclusion or removal of explicit "out of scope" paragraphs in the ietf-te-service-mapping document.
Action Item: Co-authors of working group documents are requested to verify and correct all author and contributor email addresses, as one was found to be bouncing.

Next Steps

Working Group members are encouraged to review ietf-pcc-use-cases in anticipation of its Last Call.
Working Group members are encouraged to review rfc3272bis, particularly providing input on the proposed scope change.
Working Group members are encouraged to review ietf-te-base-yang for its upcoming Last Call, and subsequently the RSVP and MPLS Yang drafts.
Discussion on the teas mailing list is encouraged for:
- Clarifying the relationship between ietf-enhanced-vpn-framework and IETF network slices.
- Reviewing the use of empty containers for future augmentation in ietf-te-vpn.
- Further discussion on the "out of scope" statements in ietf-te-service-mapping.
A Yang Doctors review for ietf-te-telemetry will be initiated, which will include review by ADs from the OPS area to address terminology.
Authors of ietf-te-service-mapping will consider adding more examples to the document.
Offline discussion between Adrian Farrel and Tarik will take place to align terminology for connectivity matrices with the te-topology model.
Further discussion is anticipated on the precise definition and implications of "Customer Endpoint (CE)" within the context of the ietf-te-framework and network slicing.

Session Date/Time: 09 Nov 2021 16:00

teas

Summary

The session resumed with a deep dive into the IETF Network Slice framework document, focusing on definitions of connectivity matrices, endpoints, and alignment of terminology. Key discussions centered on the necessity and modeling of multiple connectivity matrices per slice, the precise definition of "customer" and "endpoint," and the scope of "technology agnosticism." The chairs highlighted the importance of moving the framework document towards last call to unblock other related work.

Several individual drafts were presented, including an NBI model for network slices, a solution for realizing network slices in IP/MPLS, scalability considerations for VPN+ and VTN, a YANG model for slice policy, an application of IETF Network Slices in 5G, a framework for end-to-end IETF Network Slicing, a topology filter YANG model, and new work on intent-based routing. Many authors requested working group adoption for their drafts, prompting discussions on terminology alignment and overlap with existing work.

Key Discussion Points

IETF Network Slice Framework (Adrian Farrel):
- Connectivity Matrix (CM) Definition: Extensive discussion around the definition of CMs.
  - Tarik queried the need for an "uber grouping" of CMs for class of service (CoS) criteria, suggesting a shift from customer-facing slice description to network realization. Adrian acknowledged the likely need.
  - Reza proposed clarifying CMs into unicast/multicast categories (point-to-point vs. point-to-multipoint) and requested a clear definition of "matrix" (X sender, Y receiver) for alignment with NBI/service YANG models.
  - Kiran raised concerns about the distinction between CE-to-CE and PE-based provisioning, suggesting a single unicast flow as a fundamental building block.
  - Greg clarified that CMs are distinct from data flows, as unicast traffic can traverse a point-to-multipoint CM.
  - Jack emphasized that CMs define connectivity models (point-to-cloud, cloud-to-point, cloud-to-cloud) and SLAs, not traffic types, and that confusing traffic with connectivity models should be avoided.
  - Adrian acknowledged the diversity of opinions and the need for further discussion on the mailing list.
- Draft -05 Changes Summary:
  - Allowed for multiple CMs per slice (subject to CM definition changes).
  - Refined service definition, with endpoint definition being a key issue.
  - Added a figure illustrating endpoint positions (CE port, PE port, in PE) and introduced "ancillary CE" for service functions.
  - Included a realization process figure, which needs clearer textual descriptions.
  - Workflow agreed upon: no specific order mandated for operations.
- Further Issues:
  - Need for an editorial pass to remove stale text and duplication.
  - Factor in review comments (e.g., Louie's).
  - Open question on endpoint definition: explore "service demarcation point" or "service attachment point" for consistency with ops area YANG models (L3SM, L2SM). This may aid CM discussion.
- NBI/SBI Alignment with RFC 8309:
  - Proposed aligning NBI/SBI terminology with RFC 8309 to reduce confusion between southbound and northbound interfaces.
  - "IETF network slice service interface" suggested for NBI. SBI terminology (network model vs. network configuration model) remains under debate.
  - Louie questioned the "IETF slice controller" role compared to higher-layer orchestrators or lower-level controllers. Adrian clarified this as an implementation choice within a bundled controller.
  - Kriti suggested "intent model" and "implementation model" for better abstraction than "customer/network." Adrian will consider this if a robust definition of "intent" is available.
  - Reza noted that QoS is a general network characteristic, not specific to slicing, though it supports slice scope.
- Technology Agnosticism:
  - Clarification sought on the statement "technology agnostic."
  - Consensus that the service is agnostic to the technology in the underlay network, but the customer's traffic and attachment circuits are technology-specific. The agnostic boundary needs clearer definition in the text.
IETF Network Slice NBI Draft (Reza Rakkhshani):
- Connectivity Matrix Modeling: Presented options for modeling multiple connectivity matrices within a slice.
  - Multiple CMs are needed because one Network Slice Endpoint (NSE) can send different traffic types, or the same endpoints can have different SLOs.
  - Option 1: Each CM is a one-directional connection with potentially different SLOs.
  - Option 2: A single CM can include multiple NSEs sending traffic, identified by an ID and traffic type.
  - Shafang argued against multiple CMs per slice, preferring multiple slices each with one CM for simplicity. This is a working group decision point.
- Other Aspects: Proposed "network slice connection groups" for aggregating characteristics when one endpoint sends to multiple others (e.g., total traffic quota). Co-authors believe a "tag" for association between IETF NS and higher-layer consumers, which was previously removed, is needed. Also discussed influencing the Network Slice Controller from the orchestrator for underlay realization.
- Italo clarified the traffic classification implications for the two CM options.
Solution to Realize Network Slices in IP/MPLS Networks (Tarik Paya):
- Updates: Incorporated "Network Resource Partition" (NRP) as agreed on the teas mailing list. Expanded realization steps for IETF NS in transport networks using "slice aggregates."
- Terminology: Defined Slice Aggregate, Network Resource Partition (NRP), and Slice Policy, clarifying their distinct roles.
- Review Comments: Editorial comments addressed. Attempted to incorporate SR building blocks (Zafar), but alignment is still pending. Clarified that DiffServ is not mandated but enables hierarchical QoS.
- Jimmy requested more generic terms for slice realization and clarification of "slice aggregate." Robin expressed confusion over "slice aggregate" meaning changes. Zafar noted ongoing discussions for combining his SR building block draft.
Scalability Considerations for VPN+ and VTN (Jian Li):
- Recap: VTN (Virtual Transport Network) used as a virtual underlay for enhanced VPNs/VPN+, delivering IETF NS services. Scalability is critical.
- Optimizations: Proposed control plane (shared control protocol instances/sessions, shared policy computation, hybrid control plane) and data plane (decoupling resource ID from topology-specific ID, dedicated VTN resource ID, IPv6 Hover Hub extension header) optimizations.
- Relationship to teas: VTN in VPN+ context is equivalent to NRP in IETF NS framework.
- Louie questioned the need for VTN ID in packets and requested alignment with NRP terminology.
Slice Policy YANG Model (Tarik Paya):
- Updates: Incorporated "Network Resource Partition" (NRP) by replacing "said" (slice aggregate ID) with "nrp-id." Aligned with topology filter data model.
- Daruf suggested re-evaluating "slice policy" terminology and providing more detail/references for rate/shaping description in the YANG model.
- Robin raised concerns that the data model depends on unstable data plane/control plane solutions. Bo noted a potential lack of clarity on bandwidth profiles across NRP links and data plane resource association.
Application of IETF Network Slice in 5G Context (Reza Rakkhshani):
- Context: 5G end-to-end network slices (UE to UPF) are a key use case for IETF NS, spanning RAN, Transport, and Core domains.
- Mapping: Focus on how 3GPP's Network Slice Selection ID (NSSAI) maps to transport (IETF NS). Discussed traffic from the AN to the PE needing an identifier (IDA) to map to an IETF NS (IDB), with VLAN as one potential solution.
- Kriti sought clarification if IDA is in-packet or conceptual. Reza clarified the draft explores options without implying a specific in-packet ID.
Framework for End-to-End IETF Network Slicing (Robin Li):
- Background: Builds on existing single-domain realization work, focusing on end-to-end IETF NS spanning multiple network domains.
- ID Layers: Defined different layers of IDs: 5G SNSSAI, Global VTN ID (for multi-domain IETF NS), and Local VTN ID (per domain). Local VTN ID is mandatory in packets, while others are optional.
- Tarik questioned if this constituted a new framework or if it should be covered by the existing IETF NS framework document.
Topology Filter YANG Model (Dhruv Kumar):
- Construct: Introduced a standalone data model for topology filters, applicable on native or customized topologies, resulting in a filtered set of topological elements. Includes "topology filter set" for unions.
- Augments the networks container from ietf-network.
- Adrian challenged the work, believing it overlaps with existing routing policy work and requesting comparison with BGP flow filters. Adrian ultimately objected to the work.
Intent-Based Routing (Jamin Li):
- Concept: Proposed carrying intent information in the data plane to reduce scalability challenges of seamless MPLS SR inter-domain routing.
- Terminology: Introduced "Intent (Intrinsic Information)" as a data plane concept, distinct from "Color" (control plane), but both can represent intent and be mapped.
- Advantages: Improved scalability (local intent mapping) and flexibility (intent satisfied by different solutions like SR policy or underlay NS across domains).
- The chair raised a question about whether this work belongs in the teas WG but acknowledged its traffic engineering aspects.

Decisions and Action Items

Framework Document (Adrian Farrel):
- Action: Adrian to fold in comments on Connectivity Matrix definition and drive further discussion on the mailing list.
- Action: Adrian to post to the list regarding the open question on endpoint definition (service demarcation point / service attachment point).
- Action: Adrian to clarify text regarding the technology agnostic boundary in the framework document.
- Decision: Workflow (Issue 7) remains flexible, no further changes needed.
IETF Network Slice NBI Draft (Reza Rakkhshani):
- Action: The working group needs to discuss and decide whether multiple connectivity matrices per slice should be explicitly supported.
Solution to Realize Network Slices in IP/MPLS Networks (Tarik Paya):
- Action: Zafar and Tarik to continue discussions on aligning/combining the SR building blocks draft. The discussion should be on the mailing list.
- Decision: A working group adoption call will be sent to the mailing list.
Scalability Considerations for VPN+ and VTN (Jian Li):
- Decision: A working group adoption call will be sent to the mailing list.
- Action: Authors to ensure alignment of terminology, specifically referring to "Network Resource Partition" instead of "VTN."
Slice Policy YANG Model (Tarik Paya):
- Decision: A working group adoption call will be sent to the mailing list.
- Action: Authors to elaborate on descriptions for rate/shaping and consider refining terminology (e.g., "network partition policy").
Framework for End-to-End IETF Network Slicing (Robin Li):
- Action: Chairs requested authors to identify and propose specific text additions to the existing IETF Network Slice framework document, rather than maintaining a separate, short framework document.

Next Steps

IETF Network Slice Framework Document: Adrian Farrel plans to publish draft -06 in November. A thorough review by the working group is requested by the end of calendar year 2021, with the aim to resolve remaining issues in January/February 2022 and proceed to a last call before the next IETF meeting.
Pending Adoption Requests: Working group adoption calls for Tarik's IP/MPLS Solution, Jian's VPN+VTN Scalability, and Tarik's Slice Policy YANG Model will be sent to the mailing list.
Topology Filter YANG Model: The working group is requested to review the document and provide feedback, particularly addressing the concerns raised regarding potential overlap with existing routing policy work. Adrian Farrel indicated he would raise his objection with the AD.
Intent-Based Routing: Further discussion on the mailing list is encouraged for this new work. The chairs will track its progress and applicability within the teas working group.