[Idr] Mohamed Boucadair's Yes on draft-ietf-idr-flowspec-redirect-ip-12: (with COMMENT)

[Mohamed Boucadair via Datatracker <[e-mail]>]

Mohamed Boucadair has entered the following ballot position for
draft-ietf-idr-flowspec-redirect-ip-12: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-ip/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi Jeff, Wim, and Adam,

Thank you for the work put into this useful piece of work.

Thanks Linda Dunbar for the OPSDIR review and the authors for taking care of
that review.

Please find below some few comments. Feel free to ignore or grab whatever
useful for you:

# BGP Flowspec/DDoS Mitigation

CURRENT:
   This has many
   possible applications, but the primary one for many network operators
   is the distribution of traffic filtering actions for distributed
   denial of service (DDoS) mitigation.

You may consider adding an informative reference to RFC 9387 (or other better
reference you may have) for an example of how BGP FS is used in the context of
DDoS mitigation.

# Copy: isn’t “mirror” better reflect how this action is referred to in
practice?

CURRENT:
   This document specifies a new redirect-to-IP flow-spec action that
   provides a method for policy-based forwarding to redirect or copy
   matching traffic toward a specific IP address.

# Ambiguous “set”

OLD:
   When the "C" bit is set the redirection
   applies to copies of the matching packets and not to the original
   traffic stream.

NEW:
   When the "C" bit is set to 1 the redirection
   applies to copies of the matching packets and not to the original
   traffic stream.

# By default

Is there any reason why distinct levels are used for behavior with similar
constructs:

   The validation check described in [RFC8955] and [RFC8956], and
   revised in [RFC9117], SHOULD be applied by default to received flow-
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   spec routes with a "redirect-to-IP" extended community

vs.

   BGP speakers that support the extended communities defined in this
   document MUST also, by default, apply additional validation rules
            ^^^^^^^^^^^^^^^^^^^^^^

# It is about routes

OLD:
   When the best-match unicast route for the "target-address" is BGP,

NEW:
   When the best-match unicast route for the "target-address" is a BGP route,

# No characterization of invalid addresses

CURRENT:
   If the "target address" is
   invalid or unreachable then the extended community MUST be ignored.

However, there is no discussion about what is considered an invalid target
address.

# Is this “IGNORED” convention used in some flowspec documents? Why simply no
using “ignored” or even “MUST be ignored”?

CURRENT:
   Traffic Rate in bytes (Section 7.1 of [RFC8955]):
      …
      This traffic filtering action is thus IGNORED for traffic that is
      …

   Traffic Rate in packets (Section 7.2 of [RFC8955]):
      …
      This traffic filtering action is thus IGNORED for traffic that is
      …

   Terminal action (Section 7.3 of [RFC8955]):
      …
      and the non-terminal action (T == 1) is IGNORED.  Copying of
      …

   Traffic marking (Section 7.5 of [RFC8955]):
      …
      This traffic filtering action is thus IGNORED for traffic that is
      …

   SFC classifier (Section 7.4 of [RFC9015]):
      …
      This traffic filtering action is thus IGNORED for traffic that is
      …

Cheers,
Med