IDR

Summary

The IDR Working Group interim meeting focused on the progression of BGP Flowspec Version 2 (FSv2), specifically draft-ietf-idr-fsv2-ip-basic. The chairs provided a comprehensive status update on the WG's extensive document queue. Technical discussions centered on the transition to strict TLV encodings for Flowspec components, new ordering mechanisms (including a "skip-by-10" numbering scheme), and several new filter types and feedback mechanisms intended to extend the FSv2 framework.

WG Status

Sue Hares provided an update on the WG status and chartering:

The updated WG charter is under IESG review.
draft-ietf-idr-bgp-ls-link-mtu and draft-ietf-idr-bgp-ls-sr-epe-over-l2bundle are with the RFC Editor.
draft-ietf-idr-flowspec-path-redirect and draft-ietf-idr-bgp-fwd-rr are at IETF Last Call.
draft-ietf-idr-flowspec-srv6 has been sent to the IESG.
draft-ietf-idr-5g-edge-service-metadata requires a BGP-DIR review before moving to Working Group Last Call (WGLC).
The chairs are prioritizing Flowspec V2 work to clear the backlog of related filter and action drafts.

Key Discussion Points

1. BGP Flowspec V2 Core Updates

Presenters: Sue Hares and Jeffrey Haas Slides: BGP Flowspec V2

Jeffrey Haas outlined the primary goals for draft-ietf-idr-fsv2-ip-basic:

Strict TLVs: Moving away from Flowspec V1's lack of length fields to allow for incremental protocol updates.
Ordering: FSv1 was optimized for DDoS; FSv2 introduces a "User Order" field to bypass natural sorting when required by specific applications.
Mandatory/Optional Bits: A new "optional" bit in the component TLV allows an operator to signal whether a rule should still be applied if a specific node cannot support a particular component (e.g., DSCP matching).
Dependencies: Introduction of a 4-byte dependency field to tie rules together. If a mandatory component in a chain cannot be installed, the entire set of dependent rules is treated as invalid.
Component Numbering: The chairs proposed a "skip-by-10" numbering scheme (e.g., 10, 20, 30) for filter components. This allows future specifications to insert new components in the correct architectural order without breaking the natural sort.

Discussion:

Nat Kao queried the limitation of components appearing only once per NLRI, noting that multiple source/destination prefixes currently require multiple rules. Jeffrey Haas suggested that a "prefix list" component might be a more efficient solution than allowing multiple occurrences of the same component type.
Jeffrey Haas detailed error handling: syntactic failures result in session resets, while semantic issues with well-formed TLVs may result in "treat-as-withdraw" behavior.

2. Bitwise IP Filters for BGP FlowSpec

Presenter: Nat Kao Slides: Bitwise IP Filters for BGP FlowSpec

Nat Kao presented a mechanism for symmetric service load balancing using bitwise masks on IP addresses (targeting least significant bits of subscribers).

Joel Halpern questioned the deployment guideline suggesting bitwise filters should not be mixed with standard prefix filters. Nat Kao clarified that the bitwise component includes the prefix and the mask, effectively combining both matches into one operation.

3. BGP FlowSpec Based IFIT

Presenter: Xiaomin Slides: BGP FlowSpec Based IFIT

Xiaomin discussed extensions for In-situ Flow Information Telemetry (IFIT) using draft-ietf-idr-bgp-ifit-capabilities.

Jeffrey Haas asked if the IFIT attribute is intended strictly for Flowspec or if it could be used with standard Unicast NLRIs. Xiaomin confirmed it is a general BGP extension.
Jeffrey Haas and Sue Hares emphasized that if it is generic, the draft must define interaction rules for non-Flowspec NLRIs and handle cases where a node cannot support the IFIT function.

4. Flowspec Content Filter and Feedback Binding

Presenter: Yujia Gao Slides: BGP Flowspec Content Filter & Feedback Binding

Yujia Gao presented two proposals:

Content Filter: A payload match mechanism for DDoS mitigation, validated with FRR and openBGPD implementations.
Feedback Binding: A mechanism for a controller to request execution feedback (success/failure/traffic stats) from the target node.