**Session Date/Time:** 04 Nov 2025 22:00

# SPRING

## Summary

The SPRING session included updates on several existing drafts and discussions on new proposals. Key topics included clarifications for SRv6 security considerations, a unified approach for redundancy protection in SRv6, IPFIX extensions for SRv6 and SR-MPLS PSIDs, and various aspects of network resource partitioning (NRP) in Segment Routing. Interest was gauged for SRv6 OAM for C-to-C trace route, and adoption calls were initiated or encouraged for an SRv6 SFC architecture, flexible candidate path selection, and SRv6 SID list optimization. A new approach to Multipath Traffic Engineering (MPTE) using SRv6 DAGs was also presented. Throughout the session, the chairs emphasized the importance of working group engagement and discussion on the mailing list.

## Key Discussion Points

*   **Administrative Updates**
    *   The Note Well was highlighted, reminding participants of IETF policies.
    *   Attendees were asked to sign into Datatracker and speak their name at the microphone.
    *   Recap of two interim meetings since IETF 122 Madrid:
        *   SRv6 Security Document: Good discussion, recording online. Working group last call expected soon after shepherd review.
        *   NRP in SRv6 using SRv6: Discussions on how NRP should be expressed in packets; a summary was sent to the list, awaiting further opinions.
    *   Document Status:
        *   One document (DH distribution of locators) sent to the AD.
        *   Several drafts in Working Group Last Call (WGLC) process, including CSSR policy, spring resource-aware segments (awaiting second WGLC for operational considerations), and spring service expath segment (awaiting author update).
        *   Adoption call ongoing for SRv6 policies SID list optimization (ends Nov 19th).
        *   Two related adoption calls for flexible candidate path selection and eligibility concept drafts to be issued in parallel soon.
    *   Chairs emphasized the need for working group engagement and discussion on the mailing list beyond just "+1" or "support".

*   **SRv6 Security Considerations**
    *   **Updates**: Topics for further consideration deemed addressed were removed, document cleaned up. Comments from Tom Hill on clarifying ULA use and strengthening language around 96-bit SIDs were incorporated.
    *   **Discussion on "Trust Domain" vs. "Administrative Domain"**:
        *   A participant raised concerns about the definition of "trusted domain" vs. "administrative domain," noting that they are not always the same (e.g., within one company but different administrative groups or across agencies with contractual trust).
        *   Another participant clarified that existing RFCs mandate SRv6 use within a trust domain, not just an AS boundary. The current draft aims to provide better explanations of what constitutes a trust domain, not to change the fundamental policy.
        *   A participant argued that "must not" statements limit protocol capability and that the original RFC's definition of "trust domain" might have been "incorrectly done without thought to everybody that could use it," particularly enterprises with separate internal networks that might need to traverse untrusted segments.
        *   The chairs reiterated that changing existing RFC policy requires a new draft and community agreement, and this document's scope is to clarify existing mandates.
    *   **Next Steps**: Authors will propose new text around "trust domain" definitions. A wording suggestion was made to avoid "must be filtered" and instead state "is filtered" to clarify that the requirement originates from RFC 8402, not this draft.

*   **Redundancy Protection in SRv6 (Balazs)**
    *   **Motivation**: Provide a generalized protection mechanism for high availability, triggered by DetNet's service protection function but applicable generally.
    *   **Updates**: The draft has been updated to align with DetNet architecture and SPRING use cases. The key change is a simplification to a single redundancy seed, moving replication/elimination logic to the redundancy policy. This allows the redundancy function within a node to select the appropriate instance based on flow ID and sequence number.
    *   **Discussion**:
        *   A participant asked for clarification on how different flow IDs affect elimination behavior and suggested adding separate examples for replication and elimination.
        *   The author clarified that flow IDs are node-specific and can change, and the R-SID points to the redundancy function which selects the instance; the policy dictates the action.
    *   **Next Steps**: Authors encourage feedback on the recent changes.

*   **IPFIX for SRv6 and SR-MPLS PSID (Yadong Lu)**
    *   **Purpose**: Extend IPFIX to provide flow visibility for SRv6 and SR-MPLS path segments (PSIDs).
    *   **Updates**: The draft has been adopted by OPSAWG. Main changes include covering SR-MPLS PSID and adding sections on PSID use cases and refined operational considerations.
    *   Two new information elements defined: one for SRv6 PSID (100-bit IPv6 address) and one for SR-MPLS PSID (three octets for label, EXP, S fields).
    *   **Next Steps**: Welcome further review and comments.

*   **NRP in SRv6 (Interim Discussion Recap)**
    *   Chairs re-confirmed the sense of the October 14th interim meeting: there is a need to encapsulate data plane-specific NRP and RPIDs already specified in other working groups. No opposition was raised during this brief check.

*   **SR Policy Extension for Network Resource Partition (NRP) (Shangnan Wang)**
    *   **Purpose**: Describe SR policy extensions to enable NRP association and corresponding operational mechanisms.
    *   **Approaches**: Two approaches: 1) introduce resource-specific SIDs, 2) introduce a dedicated data plane NRP Select ID.
    *   **Key Points**: Each candidate path (CP) of an SR policy must be associated with an NRP. The NRP Select ID is added to the packet, and transit nodes schedule traffic to dedicated resources based on this ID.
    *   **Discussion**:
        *   A participant expressed concern about the strong statement that "each candidate path... *must* be associated with RP," finding it too restrictive for implementers and potentially boxing in implementations.
        *   The chairs suggested proposing alternative text (e.g., "should") and explaining the circumstances for such an association.
    *   **Next Steps**: Authors will consider proposing clarifying text around the "must be associated" statement.

*   **SRv6 OAM for C-to-C Trace Route in Uniform Model (Zafar Ali)**
    *   **Motivation**: Describe mechanisms for C-to-C trace route (and ICMP error communication) for providers deploying a "uniform model" in SRv6 VPNs. The uniform model allows copying TTL values from customer packets to provider headers.
    *   **Scope**: Specifically for uniform model deployments, where PEs propagate TTL values and tunnel ICMP errors back to the CE.
    *   **Working Group Home**: The draft's home is 6MAN as it concerns ICMP behavior and protocol extensions, but requires SPRING interest.
    *   **Discussion**: A poll of the room indicated interest in the work.
    *   **Next Steps**: Chairs will confirm interest on the mailing list and convey this to 6MAN chairs.

*   **SRv6 SFC Architecture with SR-Aware Functions (Wataru Imazu)**
    *   **Motivation**: Achieve comprehensive management and simplicity for Service Function Chaining (SFC) using SRv6, removing SFC proxies.
    *   **Architecture**: Follows SDN framework (RFC 7426) with a service controller and manager. Uses BGP FlowSpec, PCEP, BGP-LS, and BGP-LS service segment extensions.
    *   **Updates**: Defined handling process for network function failures (router removes SID, sends ICMP error; anycast SIDs redirect traffic).
    *   **Implementation**: Demonstrated in ITHACONs with open-source software, PCE source routing, and a manager for VNF setup/monitoring.
    *   **Next Steps**: Authors requested working group adoption. Chairs encouraged starting a discussion on the mailing list to gauge interest before formally queuing for adoption.

*   **Flexible Candidate Path Selection of SR Policy (Jiaolong Liu)**
    *   **Problem**: Active candidate path (CP) may be valid but not meet performance requirements (e.g., insufficient bandwidth, excessive delay), leading to suboptimal load sharing or service impact.
    *   **Solution**: Introduce CP eligibility state based on real-time resource usage or forwarding quality (e.g., available bandwidth, end-to-end latency).
    *   **Mechanism**: Configure thresholds for quality/resource, continuously monitor performance against thresholds, and adaptively set CP eligibility to "false" if violated. Only eligible paths participate in active path selection.
    *   **Implementation**: Running code with interoperability tests in China Mobile Lab with multiple vendors (H3C, ZTE, China Unicom), demonstrating solution effectiveness.
    *   **Discussion**:
        *   A participant (Zafar Ali) noted a high amount of overlap with another draft (eligibility concept).
        *   The chairs acknowledged this and stated that parallel adoption calls for both drafts would allow for discussion on potential consolidation. If authors can negotiate, a single consolidated draft would be welcomed.
    *   **Next Steps**: Authors requested working group adoption. Chairs will initiate parallel adoption calls for this and the eligibility concept draft in the next couple of weeks, encouraging discussion on consolidation.

*   **SRv6 SID List Optimization (Zafar Ali)**
    *   **Problem**: In cases where an SR policy endpoint (e.g., egress PE) is also represented by a SID within the SID list, there can be redundant back-to-back SIDs for the same node, which is not compression efficient.
    *   **Solution**: Exclude the last node SID in such cases.
    *   **Updates**: The draft has evolved to combine PSEF, BGP, NETCONF, and BGP-LS extensions into a base document. It also covers MSD and OAM considerations.
    *   **Next Steps**: The adoption call is ongoing (ends Nov 19th). Participants are encouraged to provide comments on the list.

*   **SRv6 Multipath Traffic Engineering (MPTE) with DAGs (Andrew Stone)**
    *   **Motivation**: Signal a Directed Acyclic Graph (DAG) instead of a single path or ECMP path to achieve significant path diversity and greater path programmability.
    *   **Concept**: Uses "junction segments" deployed on branching points in the graph. A junction segment is an SR policy on a transit node with a binding SID and multiple outgoing SID lists (potentially weighted).
    *   **Optimization**: Discussed global optimization (recomputing DAG, deploying new binding SIDs/colors, updating ingress SR policy) and local optimization (e.g., tweaking weights without full DAG redeployment).
    *   **Color Usage**: Color on junction nodes is primarily for signaling and identifying the SR policy instance, distinct from ingress service steering colors.
    *   **Next Steps**: Continue discussions, refine text (version 3/4), integrate with architecture and Yang model drafts (PCE WG), and address operational considerations (OAM, BFD). Clarify information model (regular SR policy vs. special tunnel).

## Decisions and Action Items

*   **SRv6 Security Considerations**: Authors to propose new text clarifying "trust domain" definitions and distinguishing it from "administrative domain."
*   **SR Policy Extension for Network Resource Partition (NRP)**: Authors to propose alternative text for the "must be associated with RP" statement to make it less restrictive or clarify conditions, and to generate discussion on the list.
*   **SRv6 OAM for C-to-C Trace Route in Uniform Model**: Chairs will conduct an interest poll on the mailing list to gauge SPRING working group interest in this work and communicate the result to the 6MAN chairs.
*   **SRv6 SFC Architecture with SR-Aware Functions**: Chairs will add this draft to the adoption queue. **Action Item**: Authors to initiate discussion on the mailing list to demonstrate working group engagement and interest.
*   **Flexible Candidate Path Selection of SR Policy** & **Eligibility Concept**: Chairs will initiate parallel adoption calls for both drafts in the next couple of weeks. **Action Item**: Authors and working group participants are encouraged to discuss potential consolidation of these two drafts into a single document.
*   **SRv6 SID List Optimization**: The adoption call is ongoing. **Action Item**: Working group members are encouraged to review the draft and provide comments on the mailing list.
*   **General Working Group Engagement**: Chairs reminded all participants that robust discussion and engagement on the mailing list are crucial for all drafts, especially those seeking adoption.

## Next Steps

*   All authors with drafts presented are encouraged to continue engaging the working group on the mailing list to gather feedback and demonstrate interest, particularly for drafts seeking adoption.
*   The chairs will follow up on the specific action items outlined above, including starting adoption calls and conducting interest polls.
*   The next IETF meeting will be in Shenzhen.