Markdown Version | Transcript | Recording 1 | Recording 2 | Session Materials

TEAS

Summary

The Traffic Engineering Architecture and Signaling (TEAS) Working Group met at IETF 126 to discuss the status of its active drafts, advance several key specifications toward Working Group Last Call (WGLC), and debate architectural extensions for service assurance, network slicing, and inter-operator coordination.

Key advancements include preparing several Network Resource Partition (NRP) and RSVP-TE drafts for WGLC, addressing 3GPP liaison feedback for network slice applications, and proposing a scoping reduction for Abstraction and Control of Traffic Engineered Networks (ACTN) Packet Optical Integration (POI) service assurance.

Key Discussion Points

1. Administrivia & WG Status

• Presenters: Oscar González de Dios, Pawan Beeram
• Slides: 01 Administrivia & WG Status
• The chairs presented the IETF Note Well and encouraged participants to sign in via the session data tracker.
• WG Status Update:
  • Four documents are currently in the RFC Editor queue.
  • Publication requests have been submitted for the ACTN POI applicability draft and the path computation draft.
  • An incoming liaison from ITU-T regarding updates to the IMT 2020 and IMT 2030 roadmaps was received, but its deadline has passed. No response is planned unless a volunteer steps forward.

2. WG Draft Updates (Drafts Not on Agenda)

• Presenter: Pawan Beeram
• Slides: 02 WG Draft Updates (drafts not on agenda)
• Active Draft Status:
  • draft-ietf-teas-yang-l3-te-topo: The authors resolved the routing directorate's scoping concerns. Italo Busi volunteered to act as the document shepherd to progress it to publication.
  • draft-ietf-teas-actn-pm-telemetry-autonomics and draft-ietf-teas-ns-controller-models: Currently in WGLC (ending next week). If list discussion remains low, the chairs may extend the last call by one week.
  • WGLC-Ready Drafts (Targeted before the next IETF):
    • draft-ietf-teas-ns-ip-mpls and draft-ietf-teas-nrp-scalability: Both are ready for WGLC and will be progressed together once the current last calls complete.
    • draft-ietf-teas-nrp-yang and draft-ietf-teas-yang-topology-filter: The authors of the topology filter draft addressed YANG Doctor comments (from Rashad). These two drafts will progress together.
    • draft-ietf-teas-rsvp-auth-v2 and draft-ietf-teas-rsvp-hmac-sha2: Deemed WGLC-ready pending final security reviews.
    • draft-ietf-teas-rsvp-inplace-lsp-bw-update: Outstanding comments from Arista have been resolved.
    • draft-ietf-teas-te-topology-profiles: Ready for WGLC; community review is highly encouraged to ensure applicability to non-TE use cases.

3. ACTN POI Assurance

• Presenter: Daniel King
• Slides: 03 ACTN POI Assurance
• Draft: draft-ietf-teas-actn-poi-assurance
• Discussion:
  • Daniel King proposed reducing the scope of the draft to manage packet-layer complexity. The original multi-PNC packet domain setup proved too complex for real-time VPN performance monitoring and telemetry correlation at the MDSC.
  • The proposed new scope focuses on vertical layering (packet-to-optical correlation) rather than horizontal layering, assuming a single packet PNC and multiple optical PNCs.
  • Italo Busi supported the change, noting that correlating packet issues with underlying optical issues is the core value of this work, whereas resolving multi-packet-domain SLA issues is an independent problem.
  • Oscar González de Dios requested that the authors clearly define the term "domain" (e.g., IGP domain vs. controller domain) on the mailing list to establish consensus.
  • Italo Busi clarified that "domain" refers to a subnetwork under a single PNC's control.
  • Swaminathan Ananthakrishnan asked if the simplification affects the optical domain. Daniel King clarified that the optical domain still supports multiple PNCs. Italo Busi added that having multiple optical PNCs for a single packet domain deviates slightly from the one-to-one mapping assumed in the POI applicability draft, requiring further examination.

4. Realizing Network Slices in IP/MPLS Networks

• Presenter: Tarek Saad
• Slides: 04 Realizing Network Slices in IP/MPLS Networks
• Draft: draft-ietf-teas-ns-ip-mpls
• Discussion:
  • Tarek Saad summarized updates in versions 08 and 09. Version 08 addressed eight outstanding issues (including adding appendix examples for NRP partition modes, fallback behaviors, service demarcation locations, and security threats/mitigations). Version 09 added a formal definition of "NRP domain" to the terminology.
  • For the fallback behavior, unrecognized NRP selectors default to "drop." This is a local policy decision, which can optionally be indicated within the NRP selector itself.
  • Jiming Ji asked whether the fallback indicator is carried inside the selector ID or separately. Tarek Saad clarified that the draft does not define specific data-plane encodings, leaving this decision to data-plane-specific documents.
  • Jiming Ji noted some MPLS-specific examples in the appendix (e.g., overriding service labels as NRP selectors). Tarek Saad and Pawan Beeram replied that MPLS was chosen to provide realistic, concrete examples, and they welcome contributions for other data planes.
  • Chat Log Contribution: Jie Dong noted that in Section 5.1.1 (concerning "Overloaded service identifier as NRP Selector"), the VPN identifier is used as an example alongside an MPLS label stack diagram. He suggested explicitly stating that the MPLS data plane is used as an example here.
  • The authors believe the document is mature and ready for WGLC.

5. IETF Network Slice Application in 3GPP 5G End-to-End

• Presenter: Luis M. Contreras
• Slides: 05 IETF Network Slice Application in 3GPP 5G End-to-End
• Draft: draft-ietf-teas-5g-network-slice-application
• Discussion:
  • Version 07 addresses 3GPP SA2 Liaison Statement 2006. Changes include aligning terminology with 3GPP definitions, adjusting slice identifiers, and adding details on mapping processes between 3GPP management systems and the IETF Network Slice Controller (NSC).
  • The authors plan to apply further fixes to Sections 4.2, 5.1, and 16.2, update 3GPP references to current releases, and clean up the contributor list (moving inactive members to acknowledgments to avoid progression blocks).
  • Luis M. Contreras asked the chairs if a liaison reply should be sent back to 3GPP. Pawan Beeram agreed a reply is appropriate and stated they will coordinate with the liaison manager.

6. Applicability of IETF-Defined Service and Network Data Models for Network Slice Service Management

• Presenter: Luis M. Contreras
• Slides: 06 Applicability of IETF-Defined Service and Network Data Models for Network Slice Service Management
• Draft: draft-ietf-teas-ns-models-applicability
• Discussion:
  • The draft defines the mapping of slice service model parameters to existing service and network models (e.g., L3SM, L2SM, L3NM, L2NM).
  • Recent updates focused on functional and capability alignment (e.g., SLA templates, connection groups, custom topologies, and performance monitoring) to identify gaps that might require extensions in those models.
  • The authors plan to add multi-domain realization examples and solicit feedback from the mailing list.
  • Regarding a potential home for this document, Luis M. Contreras noted prior discussions about transferring it to the OPSAWG. Pawan Beeram advised continuing the work within TEAS for now, as no formal discussions have occurred with OPSAWG yet. Oscar González de Dios noted that the upcoming OPSAWG session would be a good opportunity to discuss this.

7. ACTN Extensions for Inter-Operator Coordination

• Presenter: Takeo Miyasaka
• Slides: 14 ACTN Extensions for Inter-Operator Coordination
• This is a new, individual zero-zero draft exploring how to extend ACTN to support multi-operator, multi-administrative-domain environments. It introduces an MDSC-to-MDSC interface (MMI) to allow independent operators to share abstracted topologies and jointly establish end-to-end TE paths (e.g., for AI data center interconnections).
• Discussion:
  • Daniel King asked how this work relates to the Metro Ethernet Forum (MEF) LSO (Lifecycle Service Orchestration) APIs (like Legato), which aim to coordinate resources across providers. He questioned if MEF's work was deemed insufficient. Takeo Miyasaka responded that they are starting a gap analysis of MEF LSO to be included in the next version.
  • Dhruv Dhody noted that the original ACTN architecture assumed multi-operator coordination could be handled by having one operator's MDSC act as a CNC to another operator's MDSC. He suggested clearly defining the trust boundaries and technical distinctions between a standard multi-domain network and independent cooperative operators before designing new interfaces.
  • Daniele Ceccarelli questioned the real-world applicability of the data center use case, noting that operators rarely deploy MDSCs in data centers.
  • Italo Busi suggested looking at Figure 10 of RFC 8453 (referred to as 8345 in the transcript), which depicts an MDSC acting as a CNC, to evaluate why that existing model is insufficient for the draft's use cases.

Decisions and Action Items

• Decision: The WG agreed to reduce the scope of draft-ietf-teas-actn-poi-assurance to a single packet PNC (vertical multilayer assurance) to manage complexity.
• Action Item: Authors of draft-ietf-teas-actn-poi-assurance to post the revised scope and definition of "domain" to the mailing list for validation.
• Action Item: Chairs to initiate Working Group Last Call for draft-ietf-teas-ns-ip-mpls and draft-ietf-teas-nrp-scalability after the completion of the current WGLCs.
• Action Item: Authors of draft-ietf-teas-5g-network-slice-application to submit version 08 by September addressing sectional fixes, updated 3GPP references, and contributor list maintenance.
• Action Item: Chairs to coordinate with the liaison manager to draft a reply to the 3GPP SA2 liaison statement.
• Action Item: Takeo Miyasaka to incorporate a gap analysis of MEF LSO and address the MDSC-as-CNC architectural comments in the next version of the inter-operator coordination draft.

Session Date/Time: 22 Jul 2026 12:00

TEAS

Summary

The TEAS Working Group met to discuss several key traffic engineering initiatives, including power-aware traffic engineering, RSVP-TE extensions for native IP and SRv6 networks, Multipath Traffic Engineering (MP-TE) architecture and its corresponding signaling and data models, Multicast Traffic Engineering (MC-TE), carrying 5G network slice identifiers in IP headers, and high-performance computing/AI (HPC/AI) data models.

Polls were conducted to gauge working group interest in power-aware traffic engineering and MP-TE, showing solid support for further exploration of both topics.

Key Discussion Points

Administrivia & WG Status

• The session began with the 01 Administrivia & WG Status presentation.
• The Session Chair reminded participants of the Note Well guidelines.

Power Conserving Path Placement Strategy (PCPPS)

• Presenter: Ron Bonica
• Discussion:
  • Ron Bonica presented an updated strategy to optimize network power consumption during low-demand periods by concentrating traffic on the smallest set of links and powering down idle resources.
  • Recent draft updates replaced "power utilization" with "potential power savings" (the difference between active and sleeping power consumption) based on feedback from Carlos Pignataro, acknowledging that sleeping interfaces may still consume power on some hardware architectures.
  • The draft's status was changed from Informational to Proposed Standard due to its dependency on a linked LSR draft that defines IGP power information advertisements.
  • The Session Chair advised maintaining close coordination with the GREEN Working Group. Tony Li confirmed that coordination has occurred and that their work is aligned; the LSR/TEAS work focuses on compact IGP encoding, while the GREEN WG addresses broader YANG-based modeling.
  • Zafar Ali raised concerns about the complexity of low-level power modeling, suggesting that simpler interface- or laser-level attributes might be more practical to implement and deploy. Ron Bonica noted that power savings data can be derived programmatically or through manual configuration based on vendor spec sheets.
• Polls:
  • Poll 1: Does the WG think that Power-aware traffic Engineering is a topic of interesest for TEAS WG?
    • Yes: 29, No: 2, No Opinion: 5 (Total: 57)
  • Poll 2: Is this document a good starting point for discussing power-aware traffic Engineering ?
    • Yes: 18, No: 3, No Opinion: 16 (Total: 63)

RSVP-TE Extensions for Point-to-Point IP-TE Tunnels

• Presenter: Pavan Beeram (on behalf of co-authors Tarek Saad and Andy Smith)
• Discussion:
  • The authors revived this work (previously presented at IETF 105) to address distributed bandwidth engineering challenges in native IPv4/IPv6 networks without MPLS.
  • The solution relies on egress nodes maintaining an Egress Address Block (EAB) of private IP addresses (RFC 1918 / RFC 4193). RSVP-TE signals the path, and transit nodes program EAB routes dynamically.
  • The updated version introduces an SRv6 switching type, where EABs are taken from a dedicated SRv6 locator and programmed with SRv6 end behaviors at the egress, triggering Segment Routing Header (SRH) processing.
  • Kireeti Kompella expressed interest in referencing this draft to support the IP-controlled data plane for MP-TE.
  • Zafar Ali raised concerns that using RSVP-TE signaling introduces state into a stateless Segment Routing fabric, representing a significant deviation from the base SR architecture, and suggested this needs a larger discussion in the SPRING WG. Pavan Beeram agreed to discuss this in SPRING.
  • Lou Burger questioned the value of using IP-in-IP encapsulation instead of simple n-tuple matching. Pavan Beeram explained that using a private EAB space prevents other routing protocols from taking over EAB routes in failure scenarios, mimicking the loop-free semantics of MPLS.
  • Boris Khasanov noted in the session chat that this work correlates with the PCECC architecture.

Multipath Traffic Engineering (MP-TE)

• Presenters: Kireeti Kompella, Pavan Beeram, and Andrew Stone
• Discussion:
  • Architecture (draft-kompella-teas-mpte): Kireeti Kompella outlined the architectural goal of combining multipathing and traffic engineering using Directed Acyclic Graphs (DAGs) and "junctions" to perform optimal, weighted load balancing end-to-end. The solution supports multi-ingress and multi-egress topologies and utilizes local weight-shifting to handle link failures quickly with minimal network churn.
  • Signaling & YANG Models: Pavan Beeram presented the RSVP-TE signaling and YANG data model specifications. The signaling procedures were tightened, and the YANG model was expanded to include "DAG span constraints" (junction counts, next hops, metric margins, and retry timers). Both have prototype implementations.
  • Segment Routing Realization (draft-stone-spring-mpte-sr): Andrew Stone presented a controller-based realization of MP-TE in SR networks. It defines "junction segments" on junction nodes using SR Policy candidate paths with null endpoints and unique colors to represent the DAG. It leverages binding SIDs for hierarchical reuse and supports TI-LFA protection and path monitoring via Seamless BFD (S-BFD).
  • General Discussion:
    • Lou Burger noted that MP-TE is highly relevant to DETNET's Radio Aware WAN (RAW) and support for packet replication/protection (1+1 and 1-for-N protection). Kireeti Kompella agreed that Multicast TE (MC-TE) can help fulfill these use cases.
    • Zafar Ali strongly challenged the MP-TE architecture draft, stating that the problem has already been solved and shipped via SR Policies (RFC 9256). He criticized the draft for failing to reference RFC 9256 and characterized the lack of acknowledgment of existing SR work as academic dishonesty. Kireeti Kompella thanked Zafar for the feedback.
• Polls:
  • Poll 3: Is MP-TE a topic of interest for TEAS WG?
    • Yes: 21, No: 3, No Opinion: 8 (Total: 75)
  • Poll 4: Is this document a good starting point for discussing the architecture for MP-TE?
    • Yes: 21, No: 2, No Opinion: 3 (Total: 74)
  • Poll 5: Is this document a good starting point for defining the data model for MP-TE?
    • Yes: 16, No: 1, No Opinion: 8 (Total: 74)
  • Poll 6: Is this document a good starting point for defining the RSVP-TE based signaling for MP-TE?
    • Yes: 14, No: 3, No Opinion: 15 (Total: 74)

Multicast Traffic Engineering (MC-TE)

• Presenter: Kireeti Kompella
• Discussion:
  • Kireeti Kompella proposed applying the junction concept from MP-TE to Point-to-Multipoint (P2MP) LSPs. Rather than signaling multiple sub-LSPs (RFC 4875), which creates significant Path State Block (PSB) and Resv State Block (RSV) overhead, MC-TE introduces a Junction State Block (JSB) to collapse state on replication nodes and reduce signaling churn during leaf joins/leaves.
  • Andrew Stone pointed out that this concept overlaps significantly with SR Replication Segments (SR P2MP Policies) already defined in SPRING/BGP/PCEP and cautioned that DAG-based multicast optimization must carefully address complex loop-prevention issues.
  • Changzhou asked if the proposal supports Steiner vs. non-Steiner tree computations. Kireeti Kompella clarified that the computation is orthogonal; once the tree shape is determined, JSB is used for efficient signaling.
  • Lou Burger recalled that the sub-LSP concept in RFC 4875 allowed single-PSB state collapsing as a standard compromise for faster implementation. He suggested investigating whether the desired junction behavior can be achieved with minimal modifications to the existing sub-LSP protocols rather than creating new ones.

Carrying 5G Network Slice Identifiers in IP Headers for QoS Assurance Beyond the 3GPP Domain

• Presenter: Changzhou (on behalf of co-authors Jerry and Gong Yu)
• Discussion:
  • Changzhou presented the slides 13 Carrying 5G Network Slice Identifiers in IP Headers for QoS Assurance Beyond the 3GPP-Managed Domain.
  • The draft proposes mapping the 3GPP 32-bit slice identifier (S-NSSAI) into an IPv6 Hop-by-Hop (HbH) option (leveraging the 6man network resource option format) as packets transition from the UPF into the IP backbone. This allows backbone routers to enforce slice-specific QoS policies.
  • Nathan raised concerns about the overhead of adding 12 bytes to packet headers and questioned whether mapping the traffic to simpler QoS slice types rather than propagating the full slice ID would be a more practical approach. The presenter agreed to follow up on the mailing list.

High-Performance Computing / AI (HPC/AI) Data Models

• Presenter: Quan
• Discussion:
  • Quan presented three new drafts defining YANG models to map HPC/AI scheduling metadata, service intents, and tunnel realization.
  • The Session Chair noted that while the scheduling metadata and service intent models likely fall outside the scope of the TEAS WG, the third draft on tunnel realization (augmenting TE tunnels) could be discussed here. The presenter was encouraged to socialize the work on the mailing list.

Decisions and Action Items

• Power-Aware Traffic Engineering: The chairs will initiate a formal call for adoption on the mailing list. Authors need to maintain coordination with the GREEN WG and address simplification comments raised during the session.
• IP-TE and SRv6-TE Tunnels: Discussion on the implications of introducing RSVP-TE state into segment routing networks will be brought to the SPRING WG.
• Multipath Traffic Engineering (MP-TE): Based on strong poll results, the chairs will initiate adoption calls for the MP-TE architecture, RSVP-TE signaling, and YANG model drafts.
• 5G Network Slice Identifiers: The presenter will follow up on the mailing list regarding header overhead concerns and alternative QoS mapping designs.

Next Steps

• MP-TE Workshop: A hands-on lab workshop is planned for October to allow service providers to test and provide feedback on the CLI and telemetry aspects of the MP-TE implementation.
• Multicast TE (MC-TE): The authors plan to refine the MC-TE signaling details, prepare prototype implementations, and present a more detailed comparison against RFC 4875 at the next IETF meeting.

Related Documents

draft-ietf-teas-5g-network-slice-application, draft-ietf-teas-actn-pm-telemetry-autonomics, draft-ietf-teas-actn-poi-assurance, draft-ietf-teas-nrp-scalability, draft-ietf-teas-nrp-yang, draft-ietf-teas-ns-controller-models, draft-ietf-teas-ns-ip-mpls, draft-ietf-teas-ns-models-applicability, draft-ietf-teas-rsvp-auth-v2, draft-ietf-teas-rsvp-hmac-sha2, draft-ietf-teas-rsvp-inplace-lsp-bw-update, draft-ietf-teas-te-topology-profiles, draft-ietf-teas-yang-l3-te-topo, draft-ietf-teas-yang-topology-filter, draft-kompella-teas-mpte, draft-stone-spring-mpte-sr, draft-updates-drafts-not-on-agenda-02