Hi Alvaro, Thanks for the comments, see below.
On Fri, Jan 5, 2018 at 12:17 AM, Alvaro Retana <aretana.i...@gmail.com> 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 +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com
_______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill