I have been selected as the Routing Directorate reviewer for draft-ietf-idr-flowspec-redirect-ip-06. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir.

Summary:

This draft defines a new FlowSpec redirect-to-IP action intended to provide a simpler method of policy-based forwarding by encoding an IPv4 or IPv6 target address in new BGP extended communities.

I have some comments/questions that would be useful to address before publication.

Comments/Questions:

1- Section 2.1 first says that the redirect community is invalid if the origin AS of the FlowSpec route does not match the origin AS of the best-match unicast route for the target address. However, the subsequent bullet list includes valid cases where the target-address route is non-BGP or otherwise does not fit that simple origin-AS comparison. As written, the opening sentence reads like a general rule, while the bullets define a more detailed decision procedure. Please clarify which text is intended to be authoritative, or consider introducing the bullets with wording such as “validity is determined as follows.”

2- Section 2.1 says, “It MUST be possible to disable these additional validation checks on a per-EBGP session basis.” It is not clear to me why this is necessary for interoperability. If the intent is to require configurability, it may help to explain why it specifically needs to be per-EBGP session.

3- Section 2.2 states: "...SHOULD only be redirected if the community type matches the traffic type.". The phrase “traffic type” is ambiguous. It is not clear to me whether this refers to the FlowSpec route family, meaning IPv4 FlowSpec versus IPv6 FlowSpec, the actual packet family, meaning IPv4 packets versus IPv6 packets, or the forwarding context used for resolution.

3.1. Please clarify the expected behavior in these cases:

Case 1: An IPv4 FlowSpec rule carries an IPv6 redirect community. For example, the NLRI matches IPv4 traffic, but the action carries a redirect-to-IPv6 target address. Is that valid or invalid?

Case 2: An IPv6 FlowSpec rule carries an IPv4 redirect community. Is that valid or invalid?

Case 3: A single FlowSpec route carries both a redirect-to-IPv4 community and a redirect-to-IPv6 community. The draft discusses multiple redirect-to-IP communities in general, but it is not clear to me whether mixed address families are allowed on the same route and, if so, which actions apply.

Case 4: A route matches one packet family, but the target-address lookup is performed in a different address family or forwarding context. The draft says that the target address is looked up in the database used to resolve next-hop addresses, but it is not clear to me how such cross-family resolution is intended to interact with the rule’s own address family.

4- Related to Case 4, Section 2.2 says that packets are redirected or copied “towards the IPv4 or IPv6 address in the extended community’s Global Administrator field” and that the speaker “is expected to do a longest-prefix-match lookup of the ‘target address’ in the database it uses to resolve next-hop addresses and then forward the redirected/copied packets based on the resulting route.” It is not clear to me what determines where that lookup is performed. In particular, please clarify whether the lookup is determined by the address carried in the redirect community, by the FlowSpec rule that carries the community, or by some other rule. This seems especially important for dual-stack systems and for the interaction with Section 2.2.1, which says the “target addresses” should be looked up in the FIB of the “target VRF.”

5- Section 2.2 says “one and only best path,” which is a bit unclear to me. Since the draft later discusses multipath cases, it may be better to say more explicitly what condition is intended here, for example whether this means that there is exactly one best usable path.

6- Section 2.2 says that when multiple redirect-to-IP communities are present, the speaker “SHOULD load-share” across all target addresses according to its ECMP configuration. It is not clear to me what the operational behavior is here, especially for copy versus redirect. For example, does “load-share” mean that redirected traffic is distributed across the target addresses while copied traffic is replicated to all of them, or are both redirect and copy treated the same way? If a specific behavior is intended, it would help to define it more explicitly.

7- Section 2.2 says, “If the BGP speaker is not capable of redirecting and copying the same packet it SHOULD ignore the extended communities with C=0.” That reads to me as: ignore the redirect actions and keep the copy actions. In other words, the speaker is being told to prefer copy over redirect. I am not sure why that preference is intended, and the draft does not explain why copy should take precedence. In many operational cases, especially DDoS mitigation, redirect seems more important than copy, since redirect can steer suspicious traffic to a scrubber or other mitigation path, while copy seems more aligned with observation or monitoring. If this preference is intentional, it would help to explain the rationale.

8- Section 2.2.1 states that “the ‘redirect-to-IP’ actions described above should be applied in the context of the ‘target VRF’ matching the ‘redirect-to-VRF’ extended community.” It is not clear to me what operational behavior is intended here. Is redirect-to-VRF meant only to select the lookup context for redirect-to-IP, or is the packet first redirected into the target VRF and then subject to redirect-to-IP processing there? Since both are redirect-style actions, it would help to clarify how they are intended to work together.

9- Section 2.2.1 says, “If there are multiple ‘redirect-to-VRF’ extended communities in the route, the ‘target VRF’ SHOULD be the one that matches the ‘redirect-to-VRF’ extended community with the highest numerical value.” It is not clear to me which value is being compared here, or why choosing the highest one is the right rule. It would help to explain exactly what is meant by “highest numerical value” and why that is the intended selection criterion when multiple redirect-to-VRF communities are present.

10- Section 2.2.2 cites “SFC classifier (Section 7.4 of [RFC8955]).” I think this section reference may be incorrect. In RFC 8955, Section 7.4 is RT Redirect (rt-redirect) Sub-Type 0x08, which is also consistent with the citation used earlier in Section 2.2.1 of this draft.

11-Section 2.2.2 uses “IGNORED” in all capitals several times. I was unsure whether that capitalization is intentional, since “IGNORED” is not one of the requirements-language terms defined in Section 1.1.

Nits:

12-"... SHOULD only be redirected if the..." --> "... SHOULD only be redirected or copied if the..." ?

13- a IP forwarding -> an IP forwarding

14- precendence --> precedence

15- Please keep consistency in naming, such as redirect-to-IP, redirect-to-ip

16- C == l --> C == 1 ?

17- This section documentations the --> This section documents the

18- section Section 2.1 --> Section 2.1

19- IWidely --> Widely

20- Figure 1: Local Administrator --> Figure 1: Local Administrator field ?

Thanks for this document,

Ines.