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

[Susan Hares <[e-mail]>]

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/)
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?


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.)

Please provide an example of how this logic is applied.

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

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.

After the author set answers these questions, we will progress to an IPR call
Prior to WG LC.

Cheerily, Susan Hares