Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: 
 <DM8PR08MB7413A3AACE9FA36893437495B3F5A@DM8PR08MB7413.namprd08.prod.outlook.com>
Date: Thu, 30 Oct 2025 16:21:05 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <E8B330D7-EF49-492D-B5C0-3B9A3D46889F@pfrc.org>
References: 
 <DM8PR08MB7413A3AACE9FA36893437495B3F5A@DM8PR08MB7413.namprd08.prod.outlook.com>
To: Sue Hares <shares@ndzh.com>
Message-ID-Hash: IRYAM2G7AN5KN4WZ2HXAZRALYFLE5QS4
CC: idr <idr@ietf.org>, "wim.henderickx@gmail.com" <wim.henderickx@gmail.com>
Precedence: list
Subject: =?utf-8?q?=5BIdr=5D_Re=3A_draft-ietf-idr-flowspec-redirect-ip-04_-_Shepherd?=
 =?utf-8?q?=27s_review_prior_to_WG_LC?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/idr/6JV1x8yzWOEG5T7UojTFOfZk-W0>

Sue,


> On Oct 20, 2025, at 10:03 AM, Susan Hares <shares@ndzh.com> wrote:
>=20
> Greetings Jeff, Wim, and Adam:
> =20
> 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/)
> is an old draft.  It is reported to have many implementations
> (juniper, Cisco, Huawei). =20
> =20
> This is a shepherd=E2=80=99s review of =
draft-ietf-idr-flowspec-redirect-ip-04.txt prior to WG LC.
> =20
> I have three high-level questions.
> =20
> 1) Is the =E2=80=9CC=3D0=E2=80=9D correct in the following paragraph =
in section 2.2?
> =20
>    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=3D0.  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.
> =20
> 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.
> =20
> 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=3D0) is correct, could you give an example of how the logic =
below works.
> =20
>    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=20

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=20
Route 2 from peer: 10.0.0.2 NLRI1  redirect-ip:192.0.2.2=20

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 }



> =20
> Please provide an example of how this logic is applied.
> =20
> 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=3D0x01 subtype=3D0x0c redirect-ip =
extended community exists in their implementation.

> =20
> According to the text, it does not support the following:
> 	=E2=80=A2 Section 2 - IPv4 Extended Community,
> 	=E2=80=A2 Section 2 - IPv6 Extended Community,
> 	=E2=80=A2 Section 2 - Redirect (C=3D=3D0)
> 	=E2=80=A2 Section 2 =E2=80=93 Redirect (C=3D1)
> 	=E2=80=A2 Section 2.1 =E2=80=93 Validation
> 	=E2=80=A2 Section 2.2 =E2=80=93 Redirecting - Longest prefix =
match
> 	=E2=80=A2 Section 2.2 =E2=80=93 Redirection =E2=80=93 Best path =
ECMP
> 	=E2=80=A2 Section 2.2 =E2=80=93 Multiple community with ECMP =
load sharing
> 	=E2=80=A2 Section 2.2 =E2=80=93 Redirect-to-IP in =
Redirect-to-VRF
> =20
> 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=3D0x08 subtype=3D0x00 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