Subject: [rbridge] Unnecessary flooding through ST

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 1 Feb 2006 13:38:03 -0500

Wojtek Paprowicz, 

	These are good points you bring up.

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Wojtek Paprowicz
--> Sent: Wednesday, February 01, 2006 9:15 AM
--> To: rbridge at postel.org
--> Subject: [rbridge] Unnecessary flooding through ST
--> 
--> Hello,
--> 
--> I would like to ask all of you a question which is very 
--> important to me. Basically, Rbridges run IS-IS but not
--> only. They use spanning tree (ST) for, among others,
--> broadcast transmission.
-->

In order to avoid potential confusion, we are trying to use
the term "Ingress RBridge Tree" as opposed to "Spanning Tree"
in this case.

This tree would be used for flooding, broadcast and possibly
layer 2 multicast (at least as a default mode).

--> However, ST they use is calculated based on the information 
--> stored LSP database. As far as I know, in IS-IS, we have 
--> spfDelay timer which determines the minimum time between 
--> the start of two consecutive SPF computations. Let's assume 
--> a network below:
--> 
--> HostA <> RbridgeA <> RbridgeB <> HostB
--> 
--> Rbridge A received a frame from a host A to unknown 
--> destination (let's assume that host B just attached
--> to the network).
-->

This example is somewhat unusual because HostA has to at 
least suspect that HostB is attached to the network or it 
would not be sending frames to it.

However a similar scenario might arise by moving HostB - 
from, for example, a third port on RBridgeA to the port
on RBridgeB to which you show it attached above.  In
this case, however, frames addressed to HostB will - in
the worst case - be unicast routed to the "old location"
until such time as either HostB is rediscovered at the
"new location" or the existing RBridge table entries for
HostB are "aged out".

Even in this case, it is extremely unlikely both HostA 
and HostB would be unknown.

--> 
--> The receiving Rbridge A floods the frame by means of
--> the ST but also exchanges the information about the 
--> sending host if it was also unknown. As host B just 
--> attached it will be recognized by Rbridge B very soon. 
--> Rbridge B will generate LSP to inform others of a new
--> host. Rbridge A receives this LSP with the info on 
--> host B inside and updates its LSP database. 
-->

This seems correct, assuming both hosts are unknown.

--> The process of exchanging LSPs takes very little time. 
--> However, if Rbridge A received another frame addressed
--> to host B it will flood it again because the SPF 
--> computation didn't take place yet. spfDelay typically 
--> takes 5s (but can be tuned). Does this mean that during
--> that time any transmission from host A to host B in the
--> provided scenario will be carried by means of the ST? 
-->

There are schemes for reducing the impact of flooding for
unknown destinations.  For example, some bridges may limit 
the periodicity for flooding to each unknown destination.

There are problems with doing this in certain corner cases
and it should not be a required behavior, so cases will
arise in which continuous flooding will happen.

However, there are some natural limiting factors where some
higher layer protocol is involved - depending on the need
for HostB to eventually ACK at the higher layer for frames
it receives from HostA.  Consequently, HostA will - at some
point - stop sending frames to HostB until is has received
something from HostB in return.

There may be some very small delay between the time that
HostA starts getting replies from HostB, and the time when
RBridgeA receives (and acts on) an update from RBridgeB.
During that time, some degree of flooding may continue.

I know of no reason why this would not also happen if we
were to replace RBridges with IS-IS routers.

-->
--> In other words, Rbridge A will be flooding the network  
--> with frames from host A to host B for maximum 5s or less, 
--> if the spfDelay timer was triggered earlier, till it re-
--> computes its routing and forwarding table.
-->

It may turn out that we can work with a smaller value for
a delay timer in computing shortest paths.

Also, as a mitigating factor, it is worth noting that the
use of an SPF routing protocol will ensure that all RBridges 
(at least within a common VLAN context) are updated at about 
the same time when any new destination is learned by any of 
those same RBridges.  This means that it is not necessary
for each of N-1 RBridges to flood at least one frame for all
destinations "discovered" at an Nth RBridge - assuming full
connectivity among N RBridges.

Consequently, this should result in less flooding in densely 
connected RBridge topologies.

Finally, some people within the working group are working to
define optimizations that will further reduce the need for
flooding, as well as potentially reduce the use of the entire
IRT (Ingress RBridge Tree) in the multicast case.

--> 
--> I will be very thankful for your explanation on that. 
--> Please forgive me if I have misunderstood some aspects 
--> of Rbridges and troubled you unnecessarily.
--> 
--> ------------------------
--> With kind regards,
--> 
--> Wojtek Paprowicz
--> student of the University of Science and Technology AGH
--> Cracow, Poland
--> ------------------------
--> 
--> 
--> -- 
--> Wysokie Obroty Magazyn - nowy miesiecznik motoryzacyjny. 
--> Pierwszy numer juz w sprzedazy.
--> Wiecej informacji na: http://auto.gazeta.pl/auto/0,0.html
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->