Early Review of draft-ietf-idr-flowspec-redirect-ip-06
review-ietf-idr-flowspec-redirect-ip-06-rtgdir-early-robles-2026-04-16-00

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.