Subject: [rbridge] Unnecessary flooding through ST

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 1 Feb 2006 16:34:22 -0500

One correction, below (sorry for the lengthy discussion)...

--- [SNIP] ---
--> --> 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.

After thinking a little further about this, I must conclude
that the last sentence above is not correct, as stated and 
without further amplification.

I thought it made a good "short answer", but it does not.

Strictly speaking, the statement might be true for flooding
between RBridges.  Even in this limited sense, however, the
amount of flooding required would be much less, since the 
exposure to L2 addresses would be limited to the addresses
of the local IS-IS routers on any single shared media.

In terms of flooding into the network via egress RBridges,
clearly this would not happen if the RBridge was replaced
by an IS-IS router.

Consequently, notwithstanding the potential mitigation 
techniques and factors, the extent of flooding in the case
pointed out by Wojtek Paprowicz could be much worse than 
would be the case without the interactions between bridge
learning, STP and the SPF computation.  

That is, if there was an additonal delay in "learning" as
a result of requiring a new SPF computation.

My understanding of how we will use SPF routing in general, 
however, is that an SPF computation should not be required 
for addition of new destination reachability information,
as long as the SPF computation to the egress RBridge has 
previously been completed (and we have not also received
an indication that inter-RBridge topology has changed).
Instead, the new entry would simply be added as a "learned"
destination associated with a specific egress RBridge for
which a shortest path has already been determined.

Consequently, an SPF computation would only be required if
it has not previously been done for the egress from which
ingress RBridges have "learned" a new destination address.

The question then gets back to how likely is this scenario
and - assuming it is likely enough to be a problem - does
it make sense to do something about it (e.g. - use a shorter 
delay value) in computing an SPF for "learned" destinations? 

Since, in the worst case, an SPF computation might not have
been completed for the specific egress RBridge from which a
new destination was learned, other RBridges (that might need
to forward frames toward that egress) would either have to
perform that computation very quickly, or would flood frames 
associated with that (and possibly many other) destination(s)
throughout the entire broadcast domain.

As that should happen - at most - one time for each egress 
RBridge, this does end up making the likelihood that it may
happen comparable (within the RBridge campus) to what it 
would be if RBridges were replaced with routers.

The potential for longer term flooding throughout the entire
broadcast domain, however, argues that SPF computations MUST 
be performed each time a new RBridge is discovered and that - 
at least initially - flooding may need to be inhibited until 
shortest paths have been computed to all known RBridges.

In addition, it may be necessary to always inhibit flooding
(via the IRT) whenever a new RBridge is discovered.  But that
is a matter for further study...

--> 
--- [SNIP] ---