[rbridge] WGLC comments on problem and applicability statement

Donald Eastlake d3e3e3 at gmail.com
Thu Aug 21 12:15:52 PDT 2008


See below:

On Thu, Aug 21, 2008 at 2:03 PM, Francois Tallet (ftallet) <
ftallet at cisco.com> wrote:

>  Just a comment on section 3.3's summary:
>
> *Section 3.3:*
>
> *There was one comment that there are no transient loops in Spanning Tree.
> This is incorrect. Transient loops, however unlikely, are possible with
> Spanning Tree.*
>
>
> You actually made the comment that some people were claiming there could
> not ever be a loop with STP (I will never make that claim as I would have a
> hard time justifying what I'd been working on for 10 years;-)
>

[dee3] Of course I can't actually tell what is in some else's mind or what
their motivations are but I've heard many statement that would give many
people the false impression that there can never be temporary loops with any
version of spanning tree. I've seem presentations comparing spanning tree
with "routing" that give the false impressions that no version of spanning
tree can ever have a transient loop but that "routing protocols" routinely
have persistent loops.


> The real comment is that the draft is using what can be considered *exceptional
> *STP failure scenarios to justify TRILL's *normal* way of operation.
>

[dee3] This document is not the protocol specification. It is the problem
statement and applicability document. It sets only very broad bounds on how
whatever TRILL protocol is adopted would work. If you want to claim that it
would allow such a "way of operation", fine. But I don't see it as
specifying or justifying any particular "normal way of operation".

I'll be happy if your next draft simply acknowledges that TRILL does not
> attempt to prevent temporary loops the way STP does.
>

[dee3] It seems unlikely that the TRILL protocol will do much of anything
the same way STP does and I think that is pretty clear from the document. As
is always the case when you are requesting a change in a draft, it would be
good to provide a specific wording change suggestion.


> Regards,
>
> Francois
>

Donald


>  ------------------------------
> *From:* rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] *On
> Behalf Of *Donald Eastlake
> *Sent:* Wednesday, August 20, 2008 8:43 PM
> *To:* rbridge at postel.org
> *Subject:* [rbridge] WGLC comments on problem and applicability statement
>
>   Hi,
>
>
> Below is my summary of the Working Group Last Call comments on
> draft-ietf-trill-prob-04.txt.
>
>
> General:
>
> There appears to be a rough consensus that the draft is excessively
> critical of spanning tree and this should be corrected in several places.
>
>
> Abstract:
>
> There were a number of complaints about the abstract; however the abstract
> is reasonably consistent with the body. Rather than considering such
> complaints twice, any problems with the body should be fixed and then the
> abstract adjusted to be consistent with the revised body.
>
>
> Introduction:
>
> Comments in the draft concerning spanning tree slow convergence need, at a
> minimum, to be qualified to indicate they generally do not apply to RSTP.
>
>
> Section 2:
>
> There were complaints when 802.1Q was referenced, saying that previous
> amendment that were incorporated such as 802.1s should be referenced
> instead. And there were complaints when amendments such as 802.1s were
> referenced in other parts of the document saying that they no longer exist
> and no amendments that have been rolled into the 802.1Q base document should
> be mentioned separately.
>
> In the normal case, when not otherwise qualified, "802.1Q" should refer to
> the current IEEE 802.1Q standard at the time this draft is published and as
> specified in the References section; however, there is no particular harm in
> referring to earlier amendments that have been rolled into 802.1Q as long as
> their status is mentioned.
>
>
> Section 2.1:
>
> There was one comment that thicknet, thinnet, and hubs should not be
> mentioned because they no longer exist but the reference to them is
> historical and there are still hubs, at least, in use.
>
>
> Section 2.2:
>
> There is a statement in the draft intended to compare ECMP link-state with
> non-ECMP link state which may appear to be a comparison between ECMP
> link-state with STP. This should be clarified.
>
>
> Section 2.3:
>
> The referenced paper (reference [5] in the draft) contains serious errors
> and should probably not be referenced. But, as Francois Tallet said, "RSTP
> can indeed suffer from the usual count to infinity issue specific to
> distance vector protocols that can delay the convergence by few seconds."
>
>
> Section 2.5:
>
> That there are actually 65 trees available with MSTP and that each is used
> for forwarding a non-overlapping set of VLANs should be clarified.
>
>
> Section 3.3:
>
> There was one comment that there are no transient loops in Spanning Tree.
> This is incorrect. Transient loops, however unlikely, are possible with
> Spanning Tree.
>
>
> Section 3.4:
>
> One missing reference.
>
>
> Thanks,
>
> Donald (co-chair)
>
> =============================
>
> Donald E. Eastlake 3rd +1-508-634-2066 (home)
>
> 155 Beaver Street
>
> Milford, MA 01757 USA
>
> d3e3e3 at gmail.com
>
>
> =============================
Donald E. Eastlake 3rd +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20080821/4c39e8d1/attachment.html


More information about the rbridge mailing list