[Idr] Re: draft-ietf-idr-flowspec-redirect-ip-04 - Shepherd's review prior to WG LC

[Susan Hares <[e-mail]>]

Jeff:

Thank you for the examples.

1. The statement:

“If the BGP speaker is not capable of redirecting and

copying the same packet, it SHOULD ignore the extended communities
with C=0. “

I suggest that this statement could be improved with a parenthetical “(that is, only redirect the copy).”

2. The set of examples you gave were complete and useful.  However, I was looking for an example with a mixture of the C=0 and C=1 in the extended communities.   Could you please send these to the list?

3. Nokia’s implementation notes (either in the IDR wiki or the text) are necessary to really support 2 implementations of this draft.

Cheerily, Sue

From: Jeffrey Haas <[e-mail]>
Sent: Thursday, October 30, 2025 4:21 PM
To: Susan Hares <[e-mail]>
Cc: idr <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: draft-ietf-idr-flowspec-redirect-ip-04 - Shepherd's review prior to WG LC

Sue, > On Oct 20, 2025, at 10:03 AM, Susan Hares <[e-mail]<mailto:[e-mail]>> wrote: > > Greetings Jeff, Wim, and Adam: > > The Flow-Specification V1 action described in > draft-ief-idr-f
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<removed-link> On Oct 20, 2025, at 10:03 AM, Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:

>

> Greetings Jeff, Wim, and Adam:

>

> The Flow-Specification V1 action described in

> draft-ief-idr-flowspec-redirect-ip-04

> (https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-ip/<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJw9zk0OgyAQhuGrNKyr_CigrrzKZIBqtUIGmiZtevfKptvny7yZD3vSzqYLW0pJeeLcQYFCgJundvUltJFu3EXkjiCUplKzOmrCHl85eWzIu5U8nlPi7HphW60dvpx3UujBjFLxvAD5PB_uvbQYH3xUqgfZKYudxl4LtNpYpSw4EdAawaU1ctAnilbK0Vira9rX9H0ByHMKhPW1yq7yH74_Z7pAhw.MEUCIQDWpql5IjKUbT08lZ_xS3XScOW0YVhKHjRvf_tnUH73sQIgPmirf8na9Nb9Fof2aR3xO9QULZsAUww2kymPn_YD63s>)

> is an old draft.  It is reported to have many implementations

> (juniper, Cisco, Huawei).

>

> This is a shepherd’s review of draft-ietf-idr-flowspec-redirect-ip-04.txt prior to WG LC.

>

> I have three high-level questions.

>

> 1) Is the “C=0” correct in the following paragraph in section 2.2?

>

>    If a BGP speaker receives a flow-spec route with multiple "redirect-

>    to-IP" extended communities and this route represents the one and

>    only best path, it SHOULD load-share the redirected/copied packets

>    across all the "target addresses" according to its ECMP

>    configuration.  If the BGP speaker is not capable of redirecting and

>    copying the same packet it SHOULD ignore the extended communities

>    with C=0.  If the BGP speaker is not capable of redirecting/copying a

>    packet towards multiple "target addresses" it SHOULD

>    deterministically select one "target address" and ignore the others.

>

> The logic starts with :

> a) multiple redirect-to-ip Ext-Communities on 1 NLRI with one and only best path

>      result: load share redirected/copied packets to target addresses via ECMP

> b) what appears to be an exception in 2nd sentence.

>

> Can you clarify this text please with an example to the list?



It's all NLRI for the UPDATE like everything else in BGP, but let's stick with 1 for the example.



The logic here says:

- If you can't redirect and copy at the same time, only copy.

- If you can't load balance for redirect and/or copy, your implementation should pick one target address.



> 2.  The following paragraph in section 2.2 depends on the above paragraph.

> If (C=0) is correct, could you give an example of how the logic below works.

>

>    If a BGP speaker receives multiple flow-spec routes for the same

>    flow-spec NLRI and all of them are considered best and usable paths

>    according to the BGP speaker's multipath configuration and each one

>    carries one or more "redirect-to-IP" extended communities, the BGP

>    speaker SHOULD load-share the redirected/copied packets across all

>    the "target addresses", with the same fallback rules as discussed in

>    the previous paragraph.  Note that this situation does not require

>    the BGP speaker to have multiple peers.  (For example, BGP Add-Paths

>    [RFC7911] could be used for the flow-spec address family.)



The short form of this is "if you are willing to do ECMP load balancing in your BGP implementation across multipath paths for the same destination, do so using the redirect target addresses".



The first and second section are concerned with load balancing.  These examples only discuss redirect rather than copy for simplicity.



Example 1:



Route 1 from peer: 10.0.0.1 NLRI1 redirect-ip:192.0.2.1 redirect-ip:192.0.2.2



For the above NLRI with two redirect-ip communities, the desired ECMP for flowspec NLRI1 is { 192.0.2.1, 192.0.2.2 }



Example 2:



Route 1 from peer: 10.0.0.1 NLRI1 redirect-ip:192.0.2.1

Route 2 from peer: 10.0.0.2 NLRI1  redirect-ip:192.0.2.2



If the implementation is willing to build a BGP ECMP according to its local rules, the desired ECMP for flowspec NLRI1 is { 192.0.2.1, 192.0.2.2 }



Example 3:

Route 1 from peer: 10.0.0.1 NLRI1 redirect-ip:192.0.2.1 redirect-ip:192.0.2.2

Route 2 from peer: 10.0.0.2 NLRI1  redirect-ip:192.0.2.3 redirect-ip:192.0.2.4



The desired ECMP for NLR1 is { 192.0.2.1, 192.0.2.2, 192.0.2.3, 192.0.2.4 }







>

> Please provide an example of how this logic is applied.

>

> 3.  What does the Cisco IOS-XR support in this draft?



I don't speak for the implementation.  Per prior correspondence from Jakob Heitz, no support for the type=0x01 subtype=0x0c redirect-ip extended community exists in their implementation.



>

> According to the text, it does not support the following:

>       • Section 2 - IPv4 Extended Community,

>       • Section 2 - IPv6 Extended Community,

>       • Section 2 - Redirect (C==0)

>       • Section 2 – Redirect (C=1)

>       • Section 2.1 – Validation

>       • Section 2.2 – Redirecting - Longest prefix match

>       • Section 2.2 – Redirection – Best path ECMP

>       • Section 2.2 – Multiple community with ECMP load sharing

>       • Section 2.2 – Redirect-to-IP in Redirect-to-VRF

>

> How does the cisco implementation qualify for as a 2nd implementation.



The intention here is not to show that it implements -04 of the draft, only that it supports -00.  They do not support the redirect-ip extended community in the draft.  They have support for the prior code point and procedure governed by the type=0x08 subtype=0x00 point. This code point is flagged as deprecated in the draft.



If you have suggestion for the contents that align with the suggestions from RFC 7942 for non-conformance to the current draft, please let me know.  One option is to omit it.



Nokia has support as well and I'm hoping the coauthors will supply the contents for their end of the implementation report.



-- Jeff