Skip to main content

Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL)
draft-ietf-trill-cmt-11

Yes

(Alia Atlas)

No Objection

(Barry Leiba)
(Deborah Brungard)
(Jari Arkko)
(Martin Stiemerling)
(Spencer Dawkins)
(Stephen Farrell)
(Terry Manderson)

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

Alia Atlas Former IESG member
Yes
Yes (for -08) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2015-10-13 for -10) Unknown
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 [https://mailarchive.ietf.org/arch/msg/rtg-dir/sdJci3nJ47BjpK4cm9LVWX36WZM].
Barry Leiba Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (2015-10-14 for -10) Unknown
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.
Benoît Claise Former IESG member
No Objection
No Objection (2015-10-12 for -10) Unknown
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.
Brian Haberman Former IESG member
No Objection
No Objection (2015-10-13 for -10) Unknown
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.
Deborah Brungard Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2015-10-14 for -10) Unknown
Tina Tsuo performed the opsdir review
Kathleen Moriarty Former IESG member
No Objection
No Objection (2015-10-13 for -10) Unknown
Thanks for your work on this draft and incorporating the nits found during the SecDir review.
https://www.ietf.org/mail-archive/web/secdir/current/msg06083.html
Martin Stiemerling Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -10) Unknown