[trill] Alvaro Retana's No Objection on draft-ietf-trill-centralized-replication-11: (with COMMENT)

[Alvaro Retana <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-centralized-replication-11: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-centralized-replication/



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

I have some non-blocking comments.  I would like to see the ones related to
Normative Language addressed before publication.

- From the Abstract: "RPF checks on each RBridge MUST be calculated as if the
centralized node was the ingress RBridge..."  Using Normative Language in the
Abstract seems strange to me, specially since the same language is not used
later in the text.  The document does get to the same point later, but not with
the same language.

- The Introduction says that "...a centralized node, which SHOULD be a
distribution tree root", but Section 3 says otherwise: "The centralized node
MUST be a distribution tree root."  Suggestion: use Normative Language in just
one place.  IMO, the Introduction may not be the right place for it.

- BTW, what is a "distribution tree root"?  The definition is probably
intuitive since we're talking about replication, but explicitly defining it
would clear any possible confusion.

- I appreciate the background and the description of the problem and the
mechanism, but there's a lot of repetition.  Section 3 presents for the third
time an overview of the mechanism -- Abstract, Introduction, and Section
3...note that even the last paragraph repeats information about the replication
from this same section.

- Section 9: "An edge group using CMT [RFC7783] MUST NOT set the C-nickname
flag on the pseudo-nickname it is using. This is already mandatory behavior..."
If "already mandatory" then there's no need to use Normative Language here,
right?

- Section 11.1 ("R" and "C" Flag in the Nickname Flags APPsub-TLV):  I'm not
sure if I understand correctly, but because there's a distinction between the
R-nickname and the C-nickname, both bits should not be set at the same time,
right?  What happens if they are?  It seems that the last paragraph tries to
address that question ("due to errors")...but I'm then not sure what the action
is: "it is RECOMMENDED that the nickname be treated as if the R / C flag was
set if any Nickname Flags APPsub-TLV for that nickname has the R / C flag set."
Again, what if both are set?  And "RECOMMENDED" implies that there are reasons
not to do it this way...what are those cases?