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

[Donald Eastlake <[e-mail]>]

Hi Alvaro,

Thanks for the comments, see below.

On Fri, Jan 5, 2018 at 12:17 AM, Alvaro Retana <[e-mail]>
wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-trill-centralized-replication-11: No Objection
>
> ...
>
> ----------------------------------------------------------------------
> 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.

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.

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

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.

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

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

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

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.

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

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   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]