[rbridge] Few comments on the latest daft (RE: rbridge Digest, Vol 50, Issue 1)

Mon Jul 28 14:27:17 PDT 2008

Hi Donald,
More inline too... (highlighted in red)

				2.3 page 7:

				There is no forwarding loop in the case
described in figure 4. I met with some of the authors of [5] and I'm
relatively sad that this paper was published when the conclusion is
based on a bug present in their simulator. However, RSTP can indeed
suffer from the usual count to infinity issue specific to distance
vector protocols that can delay the convergence by few seconds.

			Can you provide some pointer to a discussion of
this issue or explain what is wrong with the description of the problem
in that paper? Has a retraction or counter paper been published? Just
saying there was a bug in their simulator does not explain to me why the
problem they describe in text does not occur.

			[FT>] I got confirmation from Prof. Eugene that
there was a race condition in a state machine of their simulator. Don't
know of any public paper. I can certainly show you what is wrong in the
convergence described in the paper if you want. I think you will find an
email from Mick Seaman regarding this in the archive of 802.1. In fact,
STP/RSTP/MST make a lot of effort to ensure there is never a forwarding
loop. Again, the count to infinity problem is real, and the solution
proposed in the paper is relevant.

	Yes, that was what I wanted, for you to, as I said, "explain
what is wrong with the description of the problem in that paper?" I have
no interest in searching through 802.1 mail archives. I'm guessing that
the problem with the paper is that the stale information can't cycle for
as long as the paper implies because the distance hits a maximum...
	[FT>] The paper is simply wrong in the way it describes the
operation during RSTP reconvergence. The paper show that RSTP opens a
loop during the simple scenario described, which is an implementation
bug. I've found back the reaction of Mick Seaman to the paper, as it
seems this is a reference you appreciate:
	http://www.ieee802.org/1/private/email2/msg03582.html
	[FT>] The mere fact that the authors, just like you, assumed
that it's normal that STP open a temporary loop during reconvergence
shows that they have little bridging experience (and it's ok, I'm not
trying to insult anyone, don't get me wrong). This common knowledge is
just derived from the way routing protocols operate and the assumption
that STP=RIP. 
	I'm not trying to say either that there can never be a bridging
loop in any case when STP is running in a network (more on this below),
but it is shocking to see this paper as a reference for anyone who is
quickly searching how STP works, and this leads to the (imo wrong)
assertions you make in the document.

	I understand that spanning tree protocols try hard to minimize
loops and that modern equipment and links are quite reliable so even
transient loops are rare. But, as far as I can tell, the claim you
repeat above, that there is "never a forwarding loop" with STP, just
isn't true. I really hate arguing based on "authority" rather than the
real technical facts, but I have spoken with Mick Seaman and Norm Finn
and they agree that transient loops are possible with loss of a
sufficient number of BPDUs or temporarily undetected changes in topology
although, as I say, this is obviously a rare occurrance in the real
world.

			3.1 page 9-10:
			I think that using STP, you are guaranteed that
there is no duplication and out of order frames. Frames in transit could
be duplicated or re-ordered while RSTP/MST converges. I think that if
TRILL relies on TTL to mitigate loops, we'll certainly get more
duplication of frames, and more often.

			What are your assumptions? A topology change
like a link to a hub coming up could result in frame duplication until
detected.

			[FT>] A single hub would not be enough to cause
a problem, but a link coming up between two hubs would definitely.
That's explicitly mentioned several times in 802.1. That's a case that
can be avoided by design. I don't think it is correct to define STP
based on this topology, that is explicitly forbidden in the spec. To
push this to the extreme, I can build on purpose a scenario where BPDUs
are filtered and STP does not converge at all. It would not be honest to
say STP does not converge based on this example;-)

	Could you provide citations to these multiple explicit mentions
in "802.1" and exactly where which 802.1 standard forbids having more
than one hub in a bridged LAN? A quick search shows no occurrences of
hub in 802.1Q and exactly one occurrence in 802.1D. That occurrence in
informational Annex K.1 when it mentions that the undetected appearance
of connectivity as a way you could get frame duplication or re-ordering,
and it gives the appearance of a link between two hubs as one example.
That annex is not normative text anyway. 

	I do not agree that there is any equivalence between (1)
dropping or garbling BPDUs due to noise or other line glitches and a
link coming up due, for example, to a hub or repeater intermittently
failing and transitioning from the failed to the non-failed state and
(2) and inserting a deliberate BPDU filter. The first is normal, albeit
unlikely, random occurrence due to the imperfections of the real world.
The second is a deliberate attempt to cause failure. In any case, I
don't think anyone said that "STP does not converge". I merely made the
true statement that transient loops are possible with STP.
	[FT>] Exactly! I perfectly agree with that and let me elaborate
my answer based on this.
	The example I gave about a device filtering BPDUs is not absurd.
For instance, Cisco is using some proprietary form of STP using a
proprietary destination mac address for its BPDUs. Some third party
devices had the really weird idea of selectively discarding those BPDUs.
As soon as you inserted such a device in a Cisco network running PVST,
you could get a permanent loop. In that case, you can say that STP does
not converge. But this is something that can hopefully be avoided, by
design. 
	STP is indeed making some assumptions on the network. You won't
be guaranteed that there is no temporary bridging loops if there are
hubs in your topology (that's just what I meant when I said it was
"forbidden", sorry about that, I'm not a native English speaker) or more
generally if STP does not see the link state changes. This property of
the network can be enforced with great accuracy by design just like you
can avoid devices filtering BPDUs. All the complex mechanisms built in
STP only make sense if you are running in such a network, and our
customers (who again, might be sensitive to 10ms forwarding loop) are
definitely using STP in an appropriate network. BTW, they are also using
point to point links between switches so that they can benefit from fast
convergence (generally sub-second with decent hw), even if it is always
mentioned that STP can only converge in 30 seconds.

	Now, once you have properly designed your network, you can still
get some loops. As you mentioned earlier, dropping BPDUs could open a
loop. But it's not as likely as you might think. STP makes the
relatively reasonable assumption that if no BPDU can go through a link,
then no data traffic is forwarded either. In order to open a loop, you
would need to loose all consecutive BPDUs that STP sends on a link
(every 2 seconds) for 30 seconds while still forwarding data traffic! A
single BPDU going through would reset the timer for 30 seconds.
Honestly, if it's not impossible, getting even a transient loop in those
conditions is pretty unlikely. In fact, you are much more likely to get
a loop as a result of an implementation bug (as the one in the simulator
of professor Eugene;-).  

	There should never be a temporary loop during the normal
operation of STP in the network, just like a plane should never crash.
It does not mean that planes never crash, just that a lot of effort has
been put so that getting a crash is not trivial.
	Unless I'm simplifying TRILL the same way you are simplifying
STP, I don't think there is any effort to prevent temporary loops with
TRILL. You just have the typical loop mitigation mechanism that is a TTL
in the frames. That's why I don't think it is appropriate at all to
justify the lack of loop prevention in TRILL by comparing its behavior
to STP. It's just like comparing flying with playing Russian roulette!
Sure, you can potentially die in both cases, but they're *very*
different.

	While the wording the draft may be overly critical of STP and
should probably be adjusted, I really get tired of these sloppy claims
of magical perfection for STP.
	[FT>]  I'm likewise tired of constantly hearing the sloppy claim
that introducing IS-IS will magically fix all the "STP flaws" from
people who just ignore the constraints imposed by bridging. I challenge
you to replace STP with IS-IS and get a safer way of doing bridging. 
	With TRILL, you have not just replaced STP, you have changed the
way bridging frames is achieved (which most likely implies new hardware
for most switch vendors, not just a software upgrade). It's not IS-IS
that decrements a TTL, it's not IS-IS that cause a frame that is not in
a routing table to be dropped instead of being flooded. Even if I
perfectly agree with the choice of IS-IS, TRILL or its equivalent could
have been implemented using OSPF, EIGRP, RIP or... STP as a control
protocol!! That's why I think claiming that TRILL is fixing "STP flaws"
is just not correct.
	Regards,
	Francois

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20080728/0945566a/attachment.html