Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging
Note: This ballot was opened for revision 07 and is now closed.
(Stewart Bryant) Yes
(Jari Arkko) No Objection
(Richard Barnes) No Objection
(Gonzalo Camarillo) No Objection
(Benoît Claise) No Objection
(Spencer Dawkins) No Objection
Like Barry, I thought this was very readable (especially given the long strings of hyphenated uppercase letters that are in every spec in this space :-) I had a couple of non-blocking comments for readability, and one question for the ADs (again, not blocking, just checking my own understanding of How Things Are Done). In Abstract IEEE 802.1 Provider Backbone Bridges (PBB) [IEEE.802.1Q-2011] defines an architecture and bridge protocols for interconnection of multiple Provider Bridge Networks (PBNs). PBB was defined in IEEE as a connectionless technology based on multipoint VLAN tunnels. PBB can be used to attain better scalability in terms of number of customer MAC addresses and number of service instances that can be supported. Did I miss where you said "better than $WHAT"? I'm sure you had something in mind ... 4. Packet Walkthrough Because of text-based graphics, the Figure 3 only shows PWs on the core-facing side; however, in case of MPLS access with spoke PWs, the PE reference model is simply extended to include the same PW Forwarder function on the access-facing side. To avoid cluttering the figure, the access-side PW Forwarder (Fwdr) is not depicted without loss of any generality. I don't think the last sentence in this paragraph means what it was likely intended to mean, (double negatives don't work well in English) but rather than try to fix it, I would suggest something like Because of text-based graphics, the Figure 3 only shows PWs on the core-facing side; however, in case of MPLS access with spoke PWs, the PE reference model is simply extended to include the same PW Forwarder function on the access-facing side. To avoid cluttering the figure, the access-side PW Forwarder (Fwdr) is not depicted. ^ ending the sentence here FOR THE ADs: in 11. Contributors The following authors contributed to this document: John Hoffmans (KPN), Geraldine Calvignac (France Telecom), Olen Stokes (Extreme Networks), Raymond Zhang and Matthew Bocci (Alcatel-Lucent). We're including the organization names because they would have been on the front page anyway, right?
(Adrian Farrel) No Objection
(Stephen Farrell) No Objection
(Brian Haberman) No Objection
(Joel Jaeggli) No Objection
Barry Leiba No Objection
I found this to be an easy-to-read document that was informative for someone not immersed in this technology. Good work.
(Ted Lemon) No Objection
I think the authors should consider whether the density of acronyms in this document is something that should be continued going forward. I am impressed that Barry found this document easy to read. I am not proposing that any changes be made to this particular document at this late date, but I would like to encourage the authors to consider a different balance in future documents. For instance, why is pseudowire abbreviated PW? SA is used twice in the document; why not write "source address"? Generally speaking you should abbreviate things that are used so frequently that it's clunky to spell it out each time, and spell everything else out so that the reader doesn't spend more time flipping back and forth between the text and the glossary than actually reading. It's possible that all these terms are used so frequently by practitioners that there's no problem, so maybe I am making too much of this, but I found that the excessive use of acronyms in this document had a really negative impact on readability.