**Session Date/Time:** 03 Jun 2024 14:00

# [IDR](../wg/idr.html)

## Summary

This interim meeting of the IDR working group focused on the design team's work for `draft-ietf-idr-flowspec-v2-ip-basic`. The primary goal was to solicit feedback on whether the chosen minimal subset effectively addresses the identified problems with Flowspec V1, particularly regarding determinism and interoperability. The discussion covered the structure of filters and actions in the basic draft, the handling of failure modes, ordering mechanisms, and the path forward for extensions.

## Key Discussion Points

*   **Focus of the Interim:** The meeting served as a design team session for `draft-ietf-idr-flowspec-v2-ip-basic`, which defines a minimal subset of Flowspec V2. The objective was to gather feedback on this subset and discuss future additions for IP filters and actions.
*   **Goals of `draft-ietf-idr-flowspec-v2-ip-basic`:**
    *   To provide a simple, minimal subset to address problems in Flowspec V1.
    *   To fix deterministic feedback issues (e.g., non-graceful TLV failures, inconsistent action conflicts across routers).
    *   To offer a base for simple DDoS applications, allowing user ordering of Flowspec V1 filters and actions.
    *   To serve as a platform for more complex expansions later.
*   **Flowspec V2 IP Basic (Filters):**
    *   Inherits rule type, match operator variables, and match values from Flowspec V1.
    *   Introduces a user order identifier and logging identifier.
    *   Rule 0 concept: Permit all traffic, with rules squeezing traffic down.
    *   The draft defines a specific type for V1 filters, with extended filter rules adding a version number for future compatibility.
    *   The TTL component, initially proposed for basic, is now moved to Extended IP filters.
    *   Flowspec V1 and V2 are considered "ships in the night" (separate but potentially coexisting). Rule ordering prioritizes Flowspec V2 (user ordered) rules, then falls back to V1 ordering (by component number).
    *   Ordering within components is left to the component specifier.
*   **Flowspec V2 IP Basic (Actions):**
    *   Two types: Extended Communities (V4/V6) and a new Community Attribute Action for V2.
    *   User-ordered actions (V2) take precedence, followed by extended communities ordered by type.
    *   Anticipated need for configuration knobs for interoperability and smooth transition from V1, which must maintain consistency.
    *   **Failure Modes:** A significant discussion point was the lack of deterministic failure handling in Flowspec V1. Four Netconf-like cases (stop, best effort, conditional go on, roll back) were presented. The chairs sought feedback on these. A proposal for handling action chains and pre-specifying conflicts was included in the draft to address this determinism issue, given a lack of alternate feedback.
    *   **Community Path Attribute:** This is envisioned for add-ons, providing more flexible bytes, transitivity flags, action ordering, and a dependency chain. Examples included RPD match/set and deterministic latency, but this is not part of the basic spec.
*   **Component Ordering and LRI Format:**
    *   Discussion on spacing component types for future AANA assignments.
    *   The LRI format uses a single integer for user ordering, which is monotonically increasing but not necessarily sequential (e.g., skipping from 2 to 99) to allow for insertion of rules. The order space is intentionally large.
    *   BGP reordering means users must define their own strategy for user ordering (e.g., 1, 2, skip a few). The specification provides deterministic ordering for Flowspec V2 followed by Flowspec V1 when coexisting.
*   **Extended IP Filters:** A new extension filter type includes a version number, allowing implementations to advertise support for specific sets of filter rules, aiding orderly forward compatibility. This balances simplicity for basic IP against the complexity of new features.
*   **Common Component Types for IPv4/IPv6:** The decision for Flowspec V2 was to have common component types across IPv4 and IPv6, even if it leaves gaps in IPv4 for V6-only headers, to avoid maintaining two separate lists.
*   **Groups and Interfaces:** Functionality for applying policies to specific groups and interfaces is not included in the `ip-basic` draft. It was noted that this functionality was not part of the "minimal mandatory subset" for the basic spec and has existing proposals for extended communities.
*   **Filter/Action Failure Handling (Continued):** The `TREAT_AS_WITHDRAW` mechanism from Flowspec V1 for broken filter formats and the action chain ordering/validity checks from V1 were imported directly into V2, deemed sufficient.

## Decisions and Action Items

### Decisions

*   The `draft-ietf-idr-flowspec-v2-ip-basic` will focus on providing a minimal and simple subset to address Flowspec V1's determinism and interoperability issues, using user ordering and deterministic feedback fixes.
*   The TTL component will be moved from the `ip-basic` draft to Extended IP filters.
*   Component types will be common across IPv4 and IPv6 to avoid maintaining separate lists.
*   Groups and Interfaces functionality will not be part of the `ip-basic` draft.
*   Flowspec V1's `TREAT_AS_WITHDRAW` for filter format failures and V1's action chain ordering/validity checks will be imported directly into Flowspec V2 for handling similar issues.

### Action Items

*   **Jeff (Chair):** To generate an email to the IDR mailing list to initiate further discussion on component IDs and their sorting mechanisms.
*   **Chairs:** To contact authors of proposed new filters to gauge discussion readiness for the next week's interim; the meeting may be cancelled if there isn't enough new content.
*   **All Participants:** To watch the mailing list for updates regarding next week's interim meeting.

## Next Steps

*   The working group intends to proceed with the adoption of the `draft-ietf-idr-flowspec-v2-ip-basic` as the core minimal subset.
*   Future interims will focus on "more IP filters," "more IP actions," and "non-IP filters and actions," which will undergo their own adoption processes.
*   The `draft-ietf-idr-flowspec-v2-filters` will serve as a framework; specific proposed filters will likely be split into new drafts.
*   An interim dedicated to actions is expected to be held on June 17th.
*   A "draft-00 interim" will be held at the end of June for authors to preview `draft-00` submissions for IETF 120 and receive feedback.
*   Continue discussion on component IDs and sorting on the IDR mailing list.