Session Date/Time: 27 Jul 2022 14:00

spring

Summary

The Spring Working Group meeting commenced with initial technical connectivity issues, leading to a delayed start. The chairs provided an update on the working group's document status, highlighting two drafts submitted to the IESG for publication and one new RFC on Segment Routing Policy Architecture. The session featured presentations and discussions on various Segment Routing topics, including circuit-style SR policies, SR path MTU, connection-oriented paths in SRv6, Network Resource Partition (NRP) ID in SRv6, generalized arguments for SRv6 segments, redundancy policy for preventive protection, SR for DetNet, and BGP SR policy extensions. Additionally, a problem statement for intent-aware routing using color was presented, along with an overview of MPLS MA encoding. Several drafts requested working group adoption, and active engagement on the mailing lists was encouraged for all discussed topics.

Key Discussion Points

Circuit-Style Segment Routing Policies
- Motivation: Enable operators to run a single network carrying both connection-less (e.g., IP/L2 VPNs) and connection-oriented (e.g., private lines) services.
- Requirements: Persistent traffic-engineered paths (stable, operator-controlled changes only), strict bandwidth commitments, end-to-end path protection (sub-50ms recovery), restoration for multiple failures, and path OAM.
- Proposed Solution: Centralized PCE for path computation and bandwidth management. Bi-directional, co-routed SR policies formed by associating forward and reverse paths. Persistent paths achieved using strict hops of unprotected adjacency SIDs. Multiple candidate paths (working, protect, restore). STAMP for OAM. PCE prevents re-optimization unless requested by operator.
- Updates: Clarified PCE role (computes disjoint working/protect paths, manages allocations), addressed maximum segment depth (MSD) limitations. Document renamed and moved to Spring WG.
- Discussion:
  - Nitzan: Questioned how protection with resource allocation and bi-directional constructs are ensured; clarified that PCE computes and allocates bandwidth for both working and protect paths.
  - Robin: Suggested aligning the work with existing SR Path Segment work, noting similarities in OAM, protection, and bi-directional paths.
  - Dhruv: Noted the extensive use of PCE.
- Decision/Action: Authors requested working group adoption.
SR Path MTU for SR Policy
- Motivation: Avoid fragmentation at the SR head-end by being aware of SR Path MTU, enable ICMP messages, ensure interoperability, and use Path MTU as a path computation constraint.
- Framework: SR head-end computes/knows Path MTU. Centralized controller (PCE/SDN) can push MTU constraints. Link MTU collection via BGP-LS.
- Definition: SR PMTU for a segment list is the minimum link MTU of all links. For candidate paths/composites, it's the minimum SR PMTU of constituent segment lists/policies.
- Computation: Defined for loose TE (minimum of all ECMPs), strict (minimum of all links), mixed, binding SID (includes encapsulation overhead), and TI-LFA repair paths. Examples showed how a controller could enforce an MTU constraint, overriding default lowest MTU choice.
- Feedback Requested: Specifically on TI-LFA SR PMTU computation/fragmentation caveats, SRv6 source node encapsulation/fragmentation caveats, and SR PMTU binding SID path computation caveats.
Connection-Oriented Path in SRv6 (Hop-by-Hop Switching)
- Motivation: Support strict TE paths in SRv6 while reducing packet header size, offering an alternative to large SRH headers or complex SRv6/MPLS interop. Aims for a uniform SRv6 network programming platform.
- Data Plane: Introduces a new set of SIDs (Endpoint X-Cap D function) where the argument field simulates an MPLS label for local allocation and swapping on each node (hop-by-hop switching).
- Control Plane: Options include PCE server communicating labels, or simulating RSVP-TE procedures using "Independent CoPS C function" SIDs for path confirmation and mapping table establishment.
NRP ID in SRv6 Segment
- Motivation: Identify Network Resource Partitions (NRPs) in a network slicing context, allowing routers to forward packets based on the NRP ID.
- Encoding: Proposes using the argument field of End.X type SIDs in SRv6 Segment Routing Headers (SRH) to carry the NRP ID.
- Non-SRv6 Nodes: For nodes that do not process SRv6 SIDs directly, a "slice prefix table" is proposed. This table maps destination addresses to NRP ID positions, allowing the NRP ID to be extracted from the IPv6 destination address.
- Framework: Head-end writes NRP ID into SIDs. SRv6 endpoints extract from local SID table. Non-SRv6 nodes look up the slice prefix table.
- Discussion:
  - Joel Halpern: Requested clarification on whether strict or loose paths are assumed and how intermediate nodes not directly addressed by an SRv6 SID would extract and process the argument bits.
  - Darren Duke: Asked if this is a hop-by-hop mechanism for every SR and non-SR node.
Generalized Arguments of SRv6 Segment
- Motivation: New features (network slicing, IBN, APN6, DetNet) use IPv6 options, SRH TLVs, increasing packet header length and processing complexity. Aims to reduce overhead, improve forwarding performance, and unify processing.
- Proposal: Structured and generalized arguments for SRv6 SIDs (End.X, End.DX) to carry instructions for multiple features.
- Methods:
  1. Template: Pre-configured templates define argument structure and bit allocation for different features.
  2. Bitmap: A bitmap in the argument indicates the presence and validity of instructions for specific features.
- SRv6 CC Compression: Discusses compatibility, ensuring C-SIDs can be placed from the most significant bit while other arguments are not shifted.
- Next Steps: Define bit-to-feature mapping, allocate argument space for specific features, gather feedback.
- Discussion:
  - Joel Halpern: Asked for clarity on feature definition and examples of how compression would work, especially with limited bit space.
  - Katan: Expressed concern that RFC 8986 (SRv6 Network Programming) defines argument usage based on explicit endpoint behavior. Generalized arguments would require a new behavior/flavor definition.
  - Greg Muravsky: Questioned the definition of "guarantee" for DetNet and how specific features like DetNet map to this generalized argument.
  - Robin: Emphasized the need for a structured argument due to multiple features being processed locally, suggesting refinement for use cases.
Redundancy Policy for Preventive Protection
- Background: A generalized protection mechanism where service packets are replicated on a redundancy node, transmitted over disjoint paths, and the first correct copy is selected at the merging node. Inspired by DetNet PARO (Packet Replication, Elimination, and Ordering).
- Previous Work: Redundancy SID and Merging SID in the data plane (adopted by Spring WG).
- Current Draft: Defines a "redundancy policy" as a variant of the SR policy, with minimal changes, to instruct packet replication and assign multiple redundancy forwarding paths.
- Structure: Introduces an optional "redundancy flag" at the candidate path level. If set, all segment lists within that candidate path are used for redundancy forwarding, not load balancing, making weights inapplicable. Optionally associated with a redundancy SID (a variant of a binding SID).
- Next Steps: Define the solution, align with SR policy, discuss alternative solutions (e.g., using multiple candidate paths for redundancy), and present BGP/PCEP extensions in future sessions.
- Discussion:
  - Mike: Suggested replicating packets across candidate paths rather than segment lists to maintain load balancing capabilities.
  - Israel: Sought clarification on whether a "redundancy binding SID" takes all semantics of a standard binding SID or if a standard binding SID can function as a redundancy SID.
  - Greg Muravsky: Asked if the merge function works on a packet-by-packet or flow basis (confirmed packet-by-packet), and recommended presenting this work to the DetNet WG due to strong similarities with PARO.
BGP SR Policy Extensions
- Segment List Identifier:
  - Motivation: Current SR Policy encoding lacks an identifier for segment lists, making tasks like reporting statistics or distributing configurations inconvenient.
  - Proposal: Add SR Policy sub-TLVs for a 4-octet numeric identifier or a symbolic name for segment lists.
  - Discussion:
    - Chungli: Noted similar ongoing work and suggested collaboration to avoid redundant drafts.
    - Katan: Mentioned that the SR Policy Yang model already has a name for segment lists and suggested that feedback on BGP SR Policy encoding should be directed to the IDR mailing list.
- Head-end Behavior:
  - Motivation: While SRv6 policies using binding SIDs have defined behaviors, BGP SR Policy does not explicitly specify head-end behavior for steering without a binding SID.
  - Proposal: Add SR Policy sub-TLVs to specify head-end behavior for Layer 3 and Layer 2 traffic in SRv6.
  - Discussion:
    - Katan: Reiterated that feedback on BGP SR Policy encoding should be directed to the IDR mailing list.
Problem Statement for Intent-Aware Routing using Color
- Background: This document merges previous problem statements from Spring and BESS WGs as suggested by chairs.
- Focus: Define requirements and use cases for building intent-aware paths across multiple domains using distributed routing, primarily focusing on BGP.
- Why BGP: Operational familiarity, expectation of higher scale, and established trust models for inter-domain peering policies.
- Content: Covers deployment scenarios, use cases, an intent-aware routing framework, and detailed technical requirements (intent, steering, deployment, scalability, network availability, and BGP protocol specifics). Placeholders remain for VPN, OAM, and multicast intent requirements.
- Scalability: Focuses on scaling the MPLS data plane through hierarchy and reducing control/data plane state via a subscription-based pull model.
- Decision/Action: Authors requested working group adoption.
- Chair Comment: If adopted, the chairs requested cleanup of the document's front page regarding editor/contributor roles. It was also stressed that technical solutions for meeting these requirements should be discussed in the IDR Working Group, not Spring.
MPLS MA Encoding (Managed Abstraction Encoding)
- Context: A brief overview of one proposal for encoding changes to the MPLS header, an active discussion topic in the MPLS WG.
- Key Features:
  - Present Indicators: Uses an "MA Lab" label as an indicator, with flags in the next LSE (TC and TTL fields) to specify "in-stack" or "post-stack" actions and their length.
  - Network Actions: Defined as either flag-based or opcode-based. Opcode-based actions can include ancillary data, scope, and length within the same LSE for hardware parser friendliness.
- Encoding Flexibility: Easily extensible for more flags, opcodes, or data. Can carry multiple opcode-based actions, allowing the encapsulating node to define their desired order.
- Backward Compatibility: Capabilities must be signaled. Designed to be ECMP friendly, avoid aliasing with existing reserved labels, not interfere with TTL propagation, and coexist with G-ACh.
- Alignment: Aligned with the MNA framework and requirements for in-stack and post-stack. Emphasizes hardware parser friendliness and MSD efficiency.
- Decision/Action: Authors requested working group adoption in the MPLS working group.

Decisions and Action Items

Circuit-Style Segment Routing Policies (draft-schmutzer-spring-sr-circuit-style-policy): The authors requested working group adoption. This will be considered by the chairs.
SR Path MTU for SR Policy (draft-mishra-spring-sr-policy-path-mtu): The authors requested specific feedback from the Spring WG experts on TI-LFA SR PMTU, SRv6 source node encapsulation, and Binding SID path computation caveats.
Generalized Arguments of SRv6 Segment (draft-mao-spring-generalized-arguments-srv6-segment): The authors will continue to refine the draft, specifically addressing feedback regarding feature definition, bit-to-feature mapping, argument length allocation, and compatibility with RFC 8986.
Redundancy Policy for Preventive Protection (draft-fan-spring-sr-redundancy-policy): The authors will discuss the solution definition, alignment with SR policy, and alternative solutions (e.g., replicating across candidate paths). Further BGP/PCEP extensions are planned.
BGP SR Policy Extensions (draft-halim-spring-bgp-sr-policy-segment-list-identifier & draft-halim-spring-bgp-sr-policy-headend-behavior): Authors are encouraged to consider feedback on the IDR mailing list for these BGP-related extensions.
Problem Statement for Intent-Aware Routing using Color (draft-shraddha-bess-spring-seamless-sr-problem-statement): The authors requested working group adoption. The chairs requested cleanup of the document's front page (editor/contributor roles) if adopted.
General: All participants are encouraged to engage on the respective mailing lists for continued technical discussions and to provide feedback on drafts.

Next Steps

The Spring Working Group chairs will initiate discussion and potential adoption calls for draft-schmutzer-spring-sr-circuit-style-policy and draft-shraddha-bess-spring-seamless-sr-problem-statement.
Authors of draft-mishra-spring-sr-policy-path-mtu, draft-mao-spring-generalized-arguments-srv6-segment, and draft-fan-spring-sr-redundancy-policy will continue to refine their drafts based on the feedback received and further discussions on the mailing list.
Discussions on draft-mao-spring-generalized-arguments-srv6-segment will include defining specific bit-to-feature mappings and space allocation.
The draft-fan-spring-sr-redundancy-policy work will include future presentations on BGP and PCEP extensions.
Technical work on implementing solutions for the draft-shraddha-bess-spring-seamless-sr-problem-statement is expected to take place in the IDR Working Group.
Continued collaboration with other working groups (e.g., DetNet for redundancy policy, MPLS for MA Encoding, PCE and IDR for SR Policy related topics) is anticipated.