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

From: Alvaro Retana <[email-masked]>
Date: Thu, 04 Jan 2018 21:17:12 -0800

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?

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 5 Jan 2018 11:34:58 -0500

Hi Alvaro,

Thanks for the comments, see below.

On Fri, Jan 5, 2018 at 12:17 AM, Alvaro Retana <[email-masked]>
wrote:
> ...

Well, the inconsistency, which was also noted by another reviewer, seemed
like a problem. When the SHOULDs were being changed to MUSTs the one in
Section 1 was missed. A -12 version of the draft has been uploaded with
that SHOULD changed to MUST to be consistent with the rest of the draft.

> would clear any possible confusion.

TRILL uses distribution trees for multi-destination packets. These trees
are grown from a root RBridge and a tree is identified by a TRILL nickname
held by the root RBridge. I suppose an entry could be added to the
terminology list in Section 2 of this draft pointing to Section 4.5
(Distribution Trees) of RFC 6325, the base TRILL protocol specification.

> 3...note that even the last paragraph repeats information about the
replication

I think major deletions of text at this stage is not a good idea...

> If "already mandatory" then there's no need to use Normative Language
here,

The sentence beginning "This is already mandatory behavior..." should
probably be deleted. It's based on the theory that RBridges using CMT would
"not know about" centralized replication which is a peculiar assumption.

> not to do it this way...what are those cases?

My belief is as follows:

   - The R-nickname flag indicates a nickname for a distribution tree root
   RBridge using centralized replication and the C-nickname flag indicates a
   nickname for an edge RBridge using centralized replication. (An RBridge can
   actually hold multiple nicknames...)
   - Setting the R-nickname flag on a nickname held by a non-root RBridge
   has no effect because the R-nickname flag will be ignored. Setting the
   R-nickname flag for a distribution tree root RBridge that doesn't actually
   implement centralized replication might attract multi-destination data from
   the edge that was unicast to that RBridge for distribution but would
   actually not be distributed.
   - Setting the C-nickname flag on a non-edge RBridge has no effect
   because the C-nickname flag is only consulted for the ingress nickname in
   the TRILL Header. If an RBridge is not an edge RBridge, its nickname should
   never appear in the ingress nickname field of the TRILL Header for a TRILL
   data packet. Setting the C-nickname flag for an edge RBridge that does not
   actually implement centralized replication would mean that the edge RBridge
   would try to normally distribute multi-destination data on the
   bi-directional distribution tree while the transit nodes in the tree would
   be pruning based on centralized distribution so it is likely the packet
   would be pruned and not distributed.
   - If both flags are set, generally one or both would be ignored. In the
   corner case of an edge RBridge that is also a distribution tree root,
   distribution works fine because the pruning is identical for centralized
   and normal distribution.

If you have multiple effective TLVs for the same nickname with inconsistent
flags, you have to default one way or the other so I think the
recommendation was included to simplify things for implementers. Unless
your code is buggy, this will only be a transient condition anyway.

Thanks,
Donald (document Shephard)
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]