spring

Summary

The Spring working group session covered updates on working group documents, last calls, and ISG submissions. A key decision was the rough consensus to adopt the compression draft, with an issue tracker to be established and a dependency on a 6man draft regarding CECIDs and RFC 4291. Several new drafts were presented, focusing on enhancing SR performance measurement, end-to-end network slicing, SRv6 inter-domain mapping, alternate marking in SRH, and applying SR concepts to service control planes (ELAN). Discussions highlighted concerns around one-way measurement, BCP 38 implications, terminology, and the necessity of new SIDs. A conceptual discussion on variable-length addresses for a unified SR forwarding plane was also held, with a note from the chair about its alignment with the Spring charter.

Key Discussion Points

Chairs' Presentation and WG Updates
- Notewell Reminder: Attendees reminded of BCP 54 for respectful and courteous discussion.
- Agenda Review: No adjustments requested for the scheduled agenda.
- Meeting Minutes: Available via notes.ietf.org (formerly etherpad.ietf.org).
- Adoption Call for Compression Draft:
  - Decision: Rough consensus was found to adopt the document.
  - The working group version will include a specified open issue section.
  - A GitHub-based issue tracker will be established for all issues, with discussions remaining on the mailing list.
  - Action Item: Posting of the Spring WG version of the draft is delayed until 6man has a draft addressing the relationship between CECIDs and RFC 4291. Suresh Krishnan has been appointed as lead author for the 6man draft.
- New Working Group Documents:
- Working Group Last Calls (WGLCs):
  - draft-ietf-spring-mpls-path-segment-len (MPLS Path Segments): Final editorial nits in progress, shepherd write-up underway. All comments must be addressed.
  - draft-ietf-spring-sr-lsh-protocol (LSH document): Last call ongoing.
- ISG Submission: draft-ietf-spring-segment-routing-policy-rad was submitted to the ISG.
Enhanced SRPM Draft (draft-gandhi-spring-enhanced-srpm-srv6-srmpls)
- Objective: Performance measurement (one-way delay, round-trip delay, loss) in SR networks (SR-MPLS, SRv6) without session reflector protocol awareness, aiming for higher session scale and faster detection.
- Mechanism: Builds on RFC 8762 (STAMP) and SRPM extensions. The session reflector uses a network programming function to add a received timestamp (T2) at a defined offset in the STAMP packet and forwards it like data traffic.
- Discussion/Concerns:
  - One-way Measurement without Reflector State: Greg questioned how one-way measurement is achieved without reflector state, suggesting a contradiction and that it might be an inaccurate round-trip measurement.
  - BCP 38/Anti-spoofing: Andrew raised concerns about using IP source/destination address swapping for the reverse path and its impact on anti-spoofing mechanisms (BCP 38). Authors noted an SR-MPLS reverse path option is also defined.
  - ECMP Safety: Stuart highlighted the need to explicitly state the requirement for an entropy label to ensure ECMP-safe measurements.
- Action Items: Authors will clarify the one-way measurement mechanism, address BCP 38 implications, explicitly state entropy label requirements for ECMP safety in the next draft version, and take further discussion to the mailing list.
- Request: Working group adoption for the draft.
SR for End-to-End IETF Network Slices (draft-tmtu-spring-sr-e2e-ietf-network-slicing)
- Objective: Define SR extensions for end-to-end IETF network slices spanning multiple domains, building on existing frameworks (ietf-network-slices, teas-enhanced-vpn).
- Mechanism: Introduces "VTN Binding Segments" (VTNBC) for SR-MPLS and SRv6, used by domain edge nodes to steer traffic into a local VTN (Virtual Transport Network). Defines four functions, e.g., n.b6.incaps, n.vtn.incaps.
- Discussion/Concerns:
  - Framework Duplication: Vishnu questioned the need for a separate "end-to-end slicing framework" document if the focus is solely on stitching VTNs.
  - "End-to-End" Terminology: Adrian cautioned against using "end-to-end" as it has a broader meaning in 3GPP and can be ambiguous in IETF contexts.
- Action Items: Authors committed to refining the draft and welcoming further comments.
SRv6 Inter-domain Mapping SIDs (draft-saleh-spring-srv6-inter-domain-mapping-sids)
- Objective: Introduces three new SRv6 N.SIDs to build SRv6 paths across multiple, potentially heterogeneous, SRv6 domains, providing service continuity.
- New SIDs:
  - n.replace: Replaces the destination address with a new SID; no segment list change (similar to MPLS swap). Used when BGP next-hop is one hop away.
  - n.replace.b6: Replaces destination address with new SID and adds an additional SRv6 header (similar to MPLS swap and push). Used when BGP next-hop is multi-hop.
  - n.db6: Decapsulates a received SRv6 header and encapsulates a new SRv6 header (for service interworking, option B style).
- Discussion/Concerns:
  - Need for n.replace: Xiao Hu questioned the necessity of n.replace given SRv6's native IPv6 forwarding advantages. Authors clarified it's for specific multi-domain scenarios like option C stitching where BGP handles path segments automatically.
  - n.db6 Scope: Katan asked for clarification on whether n.db6 is per-prefix or per-VRF. Authors confirmed it is per-prefix for service prefix advertisement in an Option B style.
  - Distinction between n.b6 and n.replace.b6: Chang Li asked for clarification when only a single SID is in the list.
  - Selection Criteria: Darren asked for an illustration of how an SR source selects one of these behaviors.
  - n.replace.b6 Necessity: Xiao Fu again questioned the need for n.replace.b6 versus n.replace.
- Action Items: Authors will update the next version of the draft with more examples, use cases, and clarification on selection criteria and the specific differences between the SIDs.
- Request: Working group review, comments, and feedback.
SRH Encapsulation for Alternate Marking (draft-gandhi-spring-srv6-alt-mark)
- Objective: Proposes carrying Alternate Marking information within an SRH TLV for SRv6 to enable passive performance measurement.
- Motivation: While IPv6 Destination Options (before SRH) can carry Alternate Marking, this requires two extension headers. Encoding it in SRH TLV avoids this, potentially simplifying operations for SRv6. The TLV format is identical to existing IPv6 Alternate Marking options.
- Discussion/Concerns:
  - Redundancy with Existing Solution: Ron questioned the need for a new mechanism when Destination Option + SRH already provides similar functionality. Authors argued this is an optimized, dedicated solution for SRv6 to avoid the operational implications of using two extension headers.
- Action Items: Further discussion on the mailing list regarding the necessity of this dedicated solution versus existing IPv6 mechanisms.
Segment Routing Concepts Applied to Service Control Plane (ELAN) (draft-wuthrich-spring-sr-elan)
- Objective: Apply SR concepts to simplify the service control plane for ELAN services, improving scale and supporting active-active redundancy.
- Mechanism:
  - Service SRGB: Assigns a global unique SID index (from an SRGB) to each service in a domain.
  - Scale Improvement: Splits pseudowire-like context (service ID, endpoint ID) into two SIDs in a segment list, drastically reducing state per node compared to traditional pseudowires.
  - Control Plane: Nodes advertise their configured services using a bitmask, significantly reducing signaling messages (one message per node for all services).
  - Active-Active Redundancy: Leverages Anycast SIDs for multi-homed devices, allowing data plane MAC learning against the Anycast SID and enabling ECMP/multipathing. Service convergence becomes an underlay convergence problem.
  - ARP Suppression: Proposes flooding ARP replies to allow nodes to learn IP-MAC bindings for ARP suppression.
- Discussion/Concerns:
  - IPv6 NDP Support: Eric asked if IPv6 NDP would also be supported. Authors confirmed it would be added.
  - Relationship to BESS Draft: Matthew and Patrice asked about the relationship to a similar draft in the BESS WG. Authors clarified this draft focuses on the architectural concepts, and the BESS draft will be updated to address the signaling aspects (e.g., BGP signaling).
- Action Items: Authors will update the draft to include IPv6 NDP support and will clarify the scope differentiation with the BESS draft.
- Chairs' Note: Spring chairs will coordinate with BESS chairs to ensure appropriate working group alignment.
Intent-Based Routing (draft-peng-spring-intent-based-routing)
- Objective: Introduce an intent-based routing mechanism to reduce the scalability challenge of end-to-end intent-based paths across multiple domains.
- Mechanism:
  - Intent: Information carried in the data plane representing a specific service requirement (e.g., low latency, high bandwidth).
  - Mapping: Intents are mapped to "Colors" (defined in SR policy, associated with an SR policy).
  - Traffic Steering: Network edge nodes abstract intent from packets, map it to a color, and steer traffic into the corresponding SR policy or underlying network slice.
- Benefits:
  - Scalability: Intent-to-SR policy mapping is local, reducing need for advertising label bindings across domains.
  - Flexibility: Allows different domains to use SR policies or network slices to satisfy the same intent.
  - Extensibility: Can enforce policies for network environment and security.
- Discussion/Concerns: Linda asked for clarification on whether intent functions similarly to QoS. Authors clarified intent is a more abstract service requirement (e.g., low latency) beyond just DSCP code points.
Source Segment for MVPN in SRv6 (draft-song-spring-mvpn-src-sid)
- Objective: Introduce the concept of a "Source Segment" (an SRv6 SID used in the IPv6 source address) for MVPN services in SRv6 networks.
- Mechanism: MVPN routing and associated information can be encapsulated within the source segment. This segment is distributed by the root node and processed by leaf nodes. Defines a set of behaviors for the source segment similar to n.dt functions.
- Benefits: Source segment is unchanged along the P2MP path (unlike destination address), enhances networking capability by allowing functions in the source space, and reuses IPv6 address allocation/management.
- Discussion/Concerns:
  - ICMP Handling: Ron asked about how ICMP messages would be handled if a packet with a SID as its source address cannot be forwarded. Authors stated it would go to the locator part of the source address.
  - Prior Discussions: Zhaohui noted similar concepts were discussed in the BEER working group regarding issues with using SIDs in source addresses. Authors stated this is not specific to BEER but generally applicable to IPv6-based multicast for MVPN.
- Action Items: Authors believe this document clarifies a valid use case for source segments and will welcome further clarification and review.
Variable Length Addresses for SR (draft-ali-spring-variable-length-addresses-for-sr)
- Objective: A conceptual proposal to unify MPLS and SRv6 forwarding planes into a single, flexible addressing approach, addressing limitations and avoiding duplication.
- Core Idea: Nodes have variable-length addresses, where no address is a prefix of another. Addresses are constructed as sequences of node prefixes followed by commands (e.g., "receive", "steer").
- Source Steering: Involves stripping prefixes (MPLS-like) or using an offset (SRH-like) for address interpretation.
- Challenges/Solutions: Variable length introduces potential for routing/decoding inconsistencies, addressed by introducing a "prefix length" argument and standardizing address space.
- Common Header: Suggests a compact, flexible header by stripping down the IPv6 header.
- Next Steps: Discussion on other forwarding differences (e.g., MTU discovery) and backward compatibility.
- Chair Comment: The chair noted that it is "very questionable whether discussing this fits at all within the charter of spring," but acknowledged it could be an IETF-wide discussion.

Decisions and Action Items

Decision: Rough consensus reached to adopt draft-ietf-spring-compressed-sid-list-encoding as a working group document.
Action Item (Chairs): Establish a GitHub-based issue tracker for the compressed SID list encoding draft.
Action Item (Chairs): Delay posting of the working group version of draft-ietf-spring-compressed-sid-list-encoding until a 6man draft addressing the relationship of CECIDs and RFC 4291 is available.
Action Item (Enhanced SRPM Authors): Address concerns regarding one-way measurement without reflector state, BCP 38/anti-spoofing implications, and explicitly state entropy label requirements for ECMP safety in the next draft version.
Action Item (SR Inter-domain Mapping SIDs Authors): Update the draft with more examples, use cases, and clarifications on SID selection criteria and the differences between n.b6 and n.replace.b6.
Action Item (SR ELAN Authors): Update the draft to include IPv6 NDP support and clarify the scope distinction with the BESS draft.
Action Item (Spring and BESS Chairs): Coordinate to ensure material related to SR ELAN services is discussed in the appropriate working group.
Action Item (SRH Alternate Marking Authors): Further discussion on the mailing list regarding the necessity of a dedicated SRH TLV solution.

Next Steps

Continued development and refinement of the draft-gandhi-spring-enhanced-srpm-srv6-srmpls (Enhanced SRPM) with a request for working group adoption.
Further refinement and feedback collection for draft-tmtu-spring-sr-e2e-ietf-network-slicing (SR for E2E IETF Network Slices) and draft-saleh-spring-srv6-inter-domain-mapping-sids (SRv6 Inter-domain Mapping SIDs).
Continued discussion on draft-gandhi-spring-srv6-alt-mark (SRH Alternate Marking) regarding its necessity.
Further development of draft-wuthrich-spring-sr-elan (SR for Service Control Plane).
Refinement of draft-peng-spring-intent-based-routing (Intent-Based Routing).
Further work and clarification on draft-song-spring-mvpn-src-sid (Source Segment for MVPN).
Mailing list discussions on draft-ali-spring-variable-length-addresses-for-sr (Variable Length Addresses), with potential for broader IETF discussion.

Automatic IETF Minutes

spring

Summary

Key Discussion Points

Decisions and Action Items

Next Steps

Related Documents