Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL)
RFC 7783

Note: This ballot was opened for revision 08 and is now closed.

(Alia Atlas) Yes

(Jari Arkko) No Objection

Deborah Brungard No Objection

Ben Campbell No Objection

Comment (2015-10-14 for -10)
1.1, 2nd paragraph: I assume the all-caps for "DOES NOT" are for emphasis, and we all know 2119 does not define that phrase. But it looks enough like 2119 language that it may confuse people.

Figure 2 is misaligned.

(Benoit Claise) No Objection

Comment (2015-10-12 for -10)
As mentioned by Tina in her OPS DIR review.

Section 5.7

After sentence about tunnelling, another sentence could be added as following.

“It should be noted that tunneling would require silicon change though CMT itself is software upgrading only.”


It can be also added in the introduction or abstract, CMT method doesn’t need hardware upgrade, this is the biggest advantage of CMT.

Spencer Dawkins No Objection

(Stephen Farrell) No Objection

(Brian Haberman) No Objection

Comment (2015-10-13 for -10)
Given the broad waiver written into the Applicability section, I am left to wonder about the more interesting multicast issues like interactions with IP multicast and actual distribution tree construction in TRILL.  I guess that is future work.

(Joel Jaeggli) No Objection

Comment (2015-10-14 for -10)
Tina Tsuo performed the opsdir review

(Barry Leiba) No Objection

Terry Manderson No Objection

(Kathleen Moriarty) No Objection

Comment (2015-10-13 for -10)
Thanks for your work on this draft and incorporating the nits found during the SecDir review.

Alvaro Retana No Objection

Comment (2015-10-13 for -10)
I have a couple of significant concerns — I don't think are at the level of a DISCUSS and should be easily resolved.

1. What is a "virtual RBridge".  Is there a formal definition and a reference?  I think we can all pretty much guess what it is, but this is a standards track document and we shouldn't be guessing.  The Abstract ("Virtual representation of the non-TRILL network with a single Rbridge…") and Section 1.1 ("…a virtual Rbridge is used to represent multiple RBridges connected to an edge CE…") seem to attempt a definition, but one talks about a non-TRILL network and the other about RBridges which are TRILL constructs.

2. Section 5.6. (Failure scenarios) presents a failure recovery algorithm and says that "implementations MAY include other failure recover algorithms."  My concern is whether having different algorithms (in the same virtual RBridge group) can cause inconsistent performance or maybe even loops.  If so, then I think that fact should be called out and maybe a recommendation put forward to have one algorithm per group.

BTW, these are the same comments put forth in Stig Venaas' RTG-Dir review — but I didn't see a reply to that [].

(Martin Stiemerling) No Objection