Andy, I think most people think of a spanning tree as being constructed over a set of bridges, so I guess that in addition to the sentences you quote, I would be happy to see a more conceptual description in the Introduction.
"The spanning tree will be formed over [some set of nodes] without the multi-homing links leading to loop formation. This is possible because each redundancy group is treated as a single node for spanning tree purposes." I'm sure this is blindingly obvious to y'all but not so much to someone new to the topic. Regards Brian On 01/10/2015 11:27, Andrew G. Malis wrote: > Brian, > > On behalf of the authors, I would like to thank you for your review. Most > of your points should be addressed as you recommend. > > I've just got a comment/question regarding your first major issue. > > Note that STP operationally is not impacted with the use of a RG. Section 2 > says: “The link between the peering PEs is not visible to the bridge > domains of the STP network. In this way, the STP will always break a > possible loop within the multi-homed STP network by breaking the whole > network into separate islands so that each is attached to one PE.” Other > than that, operation is identical to the way VPLS works now, including the > use of split-horizon to perform loop-breaking through the core. and that's > also discussed in section 2. > > Does this satisfy your first comment? > > Thanks, > Andy > > On Thu, Sep 24, 2015 at 8:56 PM, Brian E Carpenter < > [email protected]> wrote: > >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please wait for direction from your >> document shepherd or AD before posting a new version of the draft. >> >> For more information, please see the FAQ at >> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >> >> Document: draft-ietf-pwe3-iccp-stp-04.txt >> Reviewer: Brian Carpenter >> Review Date: 2015-09-25 >> IETF LC End Date: 2015-09-23 >> IESG Telechat date: 2015-10-01 >> >> Summary: Ready with issues >> -------- >> >> Comments: >> --------- >> >> The author responded helpfully to the following Last Call comments >> but a new version is needed to fix them. >> >> It's impossible for a reviewer who is not expert in the details >> of 802.1Q to check many details in this draft, so I didn't. >> >> Major Issues: >> ------------- >> >> The draft does not properly explain the theory of operation. >> The messages are defined but it is not explained when a spanning >> tree is formed. Section 4 does not help with this. I think it >> should be explained at the end of the Use Case section. >> >> The main normative reference appears to be IEEE 802.1Q-2005. The current >> standard is IEEE 802.1Q-2014, which appears to be very different. >> I think this should be discussed in the text to avoid confusion. >> >>> 3.6. STP Synchronization Data TLV >> ... >>> When the total size of the TLVs to be transmitted >>> exceeds the maximal size of a fragment, these TLVs SHOULD be divided >>> into multiple sets, delimited by multiple pairs of STP >>> Synchronization Data TLVs, and filled into multiple fragments. >> >> There needs to be discussion of what happens if a fragment >> is lost. >> >> Minor Issues: >> ------------- >> >>> 3.2.1. STP Disconnect Cause sub-TLV >> ... >>> - Disconnect Cause String >>> >>> Variable length string specifying the reason for the disconnect, >>> to be used for operational purposes. >> >> Should it be specified whether this is ASCII, UTF-8,...? >> >> Nits: >> ----- >> >> Please expand Spanning Tree Protocol in the main title. >> >> Abbreviation PE used but not defined. Also, "provider edge" means an edge, >> which is an abstract concept, not a device. If the draft is discussing >> specific devices, it should say "PE device" or "PE router" or "PE switch". >> >> Abbreviation AC used but not defined. >> >> Abbreviation CE used but not defined. >> >> > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
