Routing Bridges (RBridges): Base Protocol Specification
draft-ietf-trill-rbridge-protocol-16
Yes
(Ralph Droms)
No Objection
(Alexey Melnikov)
(Cullen Jennings)
(Dan Romascanu)
(Lars Eggert)
(Robert Sparks)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)
Note: This ballot was opened for revision 16 and is now closed.
Jari Arkko Former IESG member
Yes
Yes
(2010-02-18)
Unknown
This is excellent work and very carefully crafted text. Thank you.
Ralph Droms Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
(was Discuss)
No Objection
No Objection
(2010-02-18)
Unknown
Please close on the minor comments and nits raised in Acee Lindem's Routing Area Directorate review. Please fix Radia's coordinates as her email currently bounces.
Alexey Melnikov Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
(was Discuss)
No Objection
No Objection
(2010-01-20)
Unknown
I found the document surprisingly well-written and easy to understand (despite the complex topic).
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
(was No Record, Discuss)
No Objection
No Objection
(2010-02-17)
Unknown
Stylistic quibbles with section 3: (1) IMHO, the TRILL header figure should include the header Options field. (2) Section 3.5 should be renamed "Op-length" and should focus on Op-length (3) The bulk of the current 3.5 should be moved to a new section 3.8 "TRILL Header Options" These changes would ensure that the figure 3.1 and subsequent list are parallel with the remainder of section 3. Non-stylistic quiblle with section 3: When the data link layer is IEEE [802.3], are there any constraints on Op-length to ensure that the 64 alignment is maintained? (Found the answer in section 4, but wonder if it should be mentioned earlier!) Section 3.7.3, fourth bullet, first sentence: Sorry to nitpick, but should we explicitly state that when the most significant bit is set to 1, this indicates the nickname value was configured? Section 4.1.1, first paragraph after Figure 4.2 Another Nit, but if RBridges are permitted to support a subset of the VLAN IDs, couldn't we have a situation where two implementations supported disjoint ranges and were not interoperable? Or a I misreading that text? Section 4.1.3, second paragraph first sentence. Shouldn't this sentence state that TRILL framesforwarded by a transit RBridge use the priority present in the Outer.VLAN tag as received?