**Session Date/Time:** 22 Jul 2026 07:00 # [SPRING](../wg/spring.html) ## Summary The SPRING Working Group met during IETF 126. The session was chaired by Bruno Decraene, Joel Halpern, and Alvaro Retana. The agenda was fully packed and focused on updates to active working group documents, as well as several individual proposals tackling SRv6 deployment challenges, path verification, flow control, ICMP error handling, and PPPoE transport. Key procedural updates included the adoption of two new working group documents, ongoing last calls, and agreements to split and merge specific drafts to streamline progress. --- ## Key Discussion Points ### 1. Working Group Status and Agenda Bashing **Presenter:** Bruno Decraene * **Slides:** [Chairs' Slides](https://datatracker.ietf.org/meeting/126/materials/slides-126-spring-chairs-slides-00) * **Status Updates:** * Since IETF 125, two documents have been adopted as working group documents: * [draft-ietf-spring-sr-policy-cp-validity](https://datatracker.ietf.org/id/draft-ietf-spring-sr-policy-cp-validity) (*Validity of SR Policy Candidate Path*) * [draft-ietf-spring-sr-policy-flexible-cp-selection](https://datatracker.ietf.org/id/draft-ietf-spring-sr-policy-flexible-cp-selection) (*Flexible Candidate Path Selection of SR Policy*) * A three-week adoption call is currently running until the end of July. * **Working Group Last Calls (WGLC):** * [draft-ietf-spring-sr-redundancy-protection](https://datatracker.ietf.org/id/draft-ietf-spring-sr-redundancy-protection) (*SRv6 for Redundancy Protection*) has a newly published version (v08) with significant editorial changes. * [draft-ietf-spring-srv6-security](https://datatracker.ietf.org/id/draft-ietf-spring-srv6-security) (*Segment Routing IPv6 Security Considerations*) is in its second WGLC. Version 14 was published to address security directorate comments. The chairs believe it is ready for publication. * **IESG Evaluation:** * The draft introducing resource awareness to SR segments (under IESG evaluation) has been revised to address outstanding discusses. --- ### 2. SRv6 for Redundancy Protection **Presenter:** Balázs Varga * **Slides:** [SRv6 for Redundancy Protection](https://datatracker.ietf.org/meeting/126/materials/slides-126-spring-srv6-for-redundancy-protection-00) * **Draft:** [draft-ietf-spring-sr-redundancy-protection](https://datatracker.ietf.org/id/draft-ietf-spring-sr-redundancy-protection) * **Presentation Summary:** The draft provides a generalized protection mechanism for high availability in SRv6 networks, introducing a Redundancy SID (R-SID) and redundancy policy. Version 08 restructured Section 3 to clarify the operational details of the R-SID and redundancy policy, added sections on open-source implementations and operational considerations, and updated security aspects. Feedback from an early Routing Directorate review (Andy Smith) highlighted the complexity of adding two variable-sized arguments to a SID. The authors plan to address this in v09 by the end of summer. * **Discussion:** * Bruno Decraene suggested that given the structural changes and the technical complexity of the two arguments, the working group will likely run another last call once version 09 is published. --- ### 3. Segment Routing Policy Extension for Network Resource Partition **Presenter:** Ran Chen * **Slides:** [Segment Routing Policy Extension for Network Resource Partition](https://datatracker.ietf.org/meeting/126/materials/slides-126-spring-segment-routing-policy-extension-for-network-resource-partition-slides-126-draft-ietf-spring-sr-policy-nrp-00) * **Draft:** [draft-ietf-spring-sr-policy-nrp](https://datatracker.ietf.org/id/draft-ietf-spring-sr-policy-nrp) * **Presentation Summary:** The draft defines extensions to associate SR Policies with Network Resource Partitions (NRPs). Since adoption, updates clarified that the NRP-ID is used strictly for control/management plane candidate path validation and does not participate in candidate path selection. Data plane encapsulation uses a separate NRP Selector ID. Terminology has been updated accordingly. The authors requested a WG Last Call. * **Discussion:** * Zafar Ali raised concerns about modifying the NRP Selector ID (the data plane construct) at the candidate path level rather than treating it as an overall policy-level attribute, citing hardware implementation complexity when switching selector IDs on the fly. * Jie Dong explained that while the architecture allows different candidate paths to use different NRP-IDs, typical deployment models would keep them consistent for a given service. * Joel Halpern clarified that the discussion was specifically focused on the data-plane "selector ID" construct. The authors and Zafar Ali agreed to take the architectural discussion offline and to the mailing list. --- ### 4. SRv6 Service Programming **Presenter:** Hamed Assarpour * **Slides:** [SRv6 Service Programming](https://datatracker.ietf.org/meeting/126/materials/slides-126-spring-draft-ietf-spring-srv6-service-programming-00-00) * **Draft:** [draft-ietf-spring-srv6-service-programming](https://datatracker.ietf.org/id/draft-ietf-spring-srv6-service-programming) * **Presentation Summary:** The draft defines data plane functionality for service chaining in SRv6 and SR-MPLS. Following working group consensus, the authors split the document into two separate tracks to accommodate different data plane requirements: one for SRv6 and one for SR-MPLS. Version 00 of the newly split SRv6-specific draft was submitted with minimal changes to preserve history. The SR-MPLS companion draft will be submitted soon. * **Discussion:** * Jim Guichard emphasized the importance of this draft, noting it is a "domino" that unlocks dependent YANG models in other working groups, and urged the WG to review it promptly. --- ### 5. SID as Source Address in SRv6 **Presenter:** Feng Yang * **Slides:** [SID as source address](https://datatracker.ietf.org/meeting/126/materials/slides-126-spring-sid-as-source-address-00) * **Presentation Summary:** This proposal addresses symmetric routing issues for stateful firewalls in SRv6 networks by using the SRv6 SID as the source IPv6 address. Updates include expanding the scope to non-VPN global IP over SRv6 scenarios, detailing SID selection principles (choosing the most specific SID), clarifying ICMP/ping handling, and discussing SID compression scenarios (recommending the last segment remain uncompressed to simplify firewall processing). * **Discussion:** * Daniel Bernier pointed out that modifying the source address has broader benefits, such as optimizing Reverse Path Forwarding (RPF) for Service Function Chaining (SFC) and return path optimization. He agreed to discuss these additional use cases on the mailing list. --- ### 6. Multipath Traffic Engineering for Segment Routing **Presenter:** Andrew Stone * **Slides:** [Multipath Traffic Engineering for Segment Routing](https://datatracker.ietf.org/meeting/126/materials/slides-126-spring-multipath-traffic-engineering-for-segment-routing-01) * **Presentation Summary:** This draft explores signaling a Directed Acyclic Graph (DAG) using Segment Routing. It leverages junction nodes programmed via SR policies to perform weighted ECMP branching downstream. The document has been updated to informational since it introduces no new protocol extensions. It adds detailed guidance on running SBFD, ping, and traceroute across a DAG. * **Discussion:** * Bruno Decraene asked if any BGP or PCEP protocol extensions are required. Andrew Stone replied that none are currently needed, and successful tests were conducted using existing stacks. * A speaker asked how downstream path failures are communicated to the headend. Andrew explained that SBFD runs independently on downstream junction nodes and cascades back; if all outgoing paths of a junction node fail, the node stops processing the binding SID, triggering the upstream node's SBFD session to fail. * Greg Mirsky suggested aligning the SBFD behavior with ongoing work on BFD strict mode additions. * Pirav Shenak asked whether a centralized DAG computation is necessary when nodes could compute paths locally using FlexAlgo and ECMP. Andrew Stone replied that when routing off the shortest path to spread traffic, the path explosion makes ingress-only representation unscaleable. A DAG efficiently compresses these paths across intermediate junction nodes. * Bruno Decraene noted that SPRING adoption would wait until the TEAS WG progresses the underlying multipath TE architecture. --- ### 7. ICMP Error Handling in SRv6-based VPNs (Combined Presentation) **Presenters:** Balázs Varga and Zafar Ali * **Slides:** [draft-varhal draft-ali ICMP Error Handling in SRv6-based VPNs combine presentation](https://datatracker.ietf.org/meeting/126/materials/slides-126-spring-draft-varhal-draft-ali-icmp-error-handling-in-srv6-based-vpns-combine-presentation-00) * **Presentation Summary:** The authors presented a unified overview of two complementary drafts (`draft-varhal` and `draft-ali`) tackling ICMP error handling in SRv6 VPNs where P-nodes are not VPN-aware and may be IPv6-only. * `draft-varhal` focuses on traceroute troubleshooting by encoding VPN context in the source IP address at the ingress PE, allowing ICMP errors from P-nodes to be returned to the ingress PE and mapped back to the client CE. * `draft-ali` focuses on broader observability (e.g., MTU exceeded) by letting P-nodes forward ICMP errors along the existing data path toward the egress PE, which has the necessary VPN state to relay the packet back to the CE. The authors agreed to merge the two proposals into a single document. * **Discussion:** * Alexander Vainshtein asked how a P-node would handle layer 2 VPN services. Zafar Ali clarified that when an exception occurs, the packet goes to the slow path, which determines the appropriate forwarding action based on local policy and packet content. * Joel Halpern (speaking as co-author) suggested that the immediate priority is to agree on the merged approach, after which the working group can determine which components fall under SPRING versus 6man/Int-Area. --- ### 8. SRv6 BSID with Notification Message Relay **Presenter:** Yao Liu * **Slides:** [SRv6 BSID with Notification Message Relay](https://datatracker.ietf.org/meeting/126/materials/slides-126-spring-srv6-bsid-with-notification-message-relay-00) * **Presentation Summary:** This presentation proposed a mapping-based relay solution for ICMP errors generated inside a binding SID (BSID) tunnel. It introduces a new SID behavior (`End.B6.Encaps.Relay`) containing an argument part that serves as an identifier mapping the outer encapsulation source address back to the original client source address. This avoids MTU truncation and deep header parsing overhead. * **Discussion:** * Joel Halpern questioned whether the headend receiving the relayed ICMPv6 packet would be confused by receiving error messages for outer headers it did not generate. * Zafar Ali noted that the merged ICMP error handling proposal (from the previous session) solves this without requiring new relay states. Yao Liu countered that this draft also addresses generic P-node ping/trace use cases. * Daniel Bernier suggested merging this work as a specific flavor or use case within the SID source address draft to avoid creating separate independent specifications. The authors agreed to take the discussion offline. --- ### 9. SRv6 Path Verification **Presenter:** Feng Yang * **Slides:** [SRv6 Path Verification](https://datatracker.ietf.org/meeting/126/materials/slides-126-spring-srv6-path-verification-00) * **Presentation Summary:** This draft addresses scenarios where packets are forwarded through unexpected paths due to configuration errors or malicious injection. It proposes a hop-by-hop verification mechanism using a new Segment Routing Header (SRH) TLV containing an authentication tag and sequence numbers to prevent replay attacks. Two algorithms, HMAC-SHA and AES-CMAC, were proposed and evaluated for line-rate hardware support. * **Discussion:** * The presenter requested feedback from the working group regarding router hardware compatibility and performance for the proposed algorithms. --- ### 10. SRv6 Behavior Extension for Flow Control in WAN **Presenter:** Junxin Han * **Slides:** [SRv6 Behavior Extension for flow control in WAN](https://datatracker.ietf.org/meeting/126/materials/slides-126-spring-srv6-behavior-extension-for-flow-control-in-wan-00) * **Presentation Summary:** To extend data center lossless network mechanisms (like PFC) over wide-area networks, this proposal introduces a new SRv6 behavior: `End.X.PFC`. In the event of downstream congestion, PFC frames are encapsulated in a reverse SRv6 tunnel and steered back to the upstream PFC-capable device, bypassing non-PFC legacy devices. * **Discussion:** * There were no questions from the floor. The authors invited reviews and feedback. --- ### 11. SRv6 for PPPoE Transport **Presenter:** Shengbin Xiong * **Slides:** [SRv6 for PPPoE Transport](https://datatracker.ietf.org/meeting/126/materials/slides-126-spring-srv6-for-pppoe-transport-00) * **Presentation Summary:** The draft proposes transporting PPPoE over SRv6 to allow PPPoE servers to sit outside the local Layer 2 domain, enabling metered charging and flexible steering for high-volume data workloads. It defines new behaviors (`End.DX.Slice.PPPOE` and `End.DX.D.PPPOE`) to decapsulate the outer IPv6 and PPPoE headers and insert slice IDs directly into the inner IP header for downstream steering. * **Discussion:** * Daniel Bernier questioned whether using PPPoE over SRv6 is necessary when PPP over SRv6 could be run directly (avoiding the Ethernet shim). He also suggested bringing the subscriber steering requirements to the Broadband Forum (BBF). * Alexander Vainshtein raised a technical issue with the slide's state logic, pointing out that PPPoE is an EtherType inside the Ethernet frame rather than an upper-layer header type in SRv6. He also questioned the need for a dedicated behavior, noting that PPPoE has been successfully carried over MPLS pseudowires for two decades without requiring special pseudowire types. * Shengbin Xiong responded that standardizing native SRv6 endpoint behaviors is critical for controller-based capability advertising (via BGP) and network programmability at scale. * Joel Halpern issued a procedural reminder to the presenter and participants that financial metrics (revenue, cost, and profit) must not be discussed during IETF technical sessions. --- ## Decisions and Action Items * **`draft-ietf-spring-srv6-service-programming`**: * **Decision:** The working group agreed to split the original draft into two separate documents: one for SRv6 and one for SR-MPLS. * **Action Item:** The authors will submit the separate SR-MPLS draft shortly. * **ICMP Error Handling in SRv6-based VPNs**: * **Decision:** The authors of `draft-varhal` and `draft-ali` agreed to merge their drafts into a single document. * **Action Item:** Authors will publish a combined version. --- ## Next Steps * **`draft-ietf-spring-sr-redundancy-protection`**: Authors will publish version 09 addressing the Routing Directorate review comments regarding double SID arguments. The chairs will coordinate a new WGLC thereafter. * **`draft-ietf-spring-sr-policy-nrp`**: Discussion on the architectural placement of the NRP selector ID (candidate path level vs. policy-level attribute) will continue on the mailing list. * **Multipath Traffic Engineering**: The draft will remain on hold for adoption in SPRING until the base architecture progresses within the TEAS Working Group. * **SRv6 for PPPoE Transport**: The authors will address technical comments regarding EtherType processing and the BBF coordination on the mailing list, and will update the draft to remove legacy SID format definitions.