Re: [Gen-art] Gen-ART telechat review of draft-ietf-pwe3-iccp-stp-04

["Andrew G. Malis" <[e-mail]>]

Brian,

Thanks, I'll ask the authors to add that.

Cheers,
Andy

On Wed, Sep 30, 2015 at 8:12 PM, Brian E Carpenter <
[e-mail]> wrote:

> 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 <
> > [e-mail]> 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.
> >>
> >>
> >
>
>