Subject: [bess] Alvaro Retana's No Objection on draft-ietf-bess-evpn-optimized-ir-09: (with COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Thu, 21 Oct 2021 06:56:04 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-bess-evpn-optimized-ir-09: No Objection

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/blog/handling-iesg-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-bess-evpn-optimized-ir/

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

Thanks to Julien Meuric for the rtg-dir review.  Please reply to it.

(1) §4:
   -  T is the AR Type field (2 bits) that defines the AR role of the
...
     o  11 (decimal 3) = RESERVED

What should a receiver do if the reserved value is received?

(2) §4:

   Each AR-enabled node MUST understand and process the AR type field in
   the PTA (Flags field) of the routes, and MUST signal the
   corresponding type (1 or 2) according to its administrative choice.

"MUST understand and process the AR type field"

>From a normative action point of view, this statement has no value as it is
equivalent to saying that the AR node has to support this document...   Please
remove the normative statement.

(3) §5.1: "The Replicator-AR and Regular-IR routes are generated according to
section 3."   s/3/4

(4) §7: "As described in section 3..."  s/3/4

(5) §5.2: The non-existence of an AR-REPLICATOR results in the AS-LEAF having
to use regular IR.  That seems like the right/only action.  However, because
the AS-LEAF is defined as a node with "poor replication performance", it
concerns me that a rogue replicator can use a non-REPLICATOR type with the
objective of impacting the application (as described in the Introduction).

The Security Considerations already mention an attack on the AR-REPLICATOR.  It
would be good if this other vector was also added.