Subject: [rbridge] Unnecessary flooding through ST

From: rute.sofia at siemens.com (Sofia, Rute)
Date: Thu, 2 Feb 2006 09:47:54 +0100

Hello,

> --> 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.
> 

Wojtek is indeed speaking of the last case you are mentioning, i.e.,
besides IS-IS, you still have the flooding performed in the ST. It is a
fact that IS-IS has to be tuned and that anyway the spfdelay timer may
give rise to the same problems. But the problem here is indeed allowing
Rbridges to try to get info about destinations in two ways 1) on demand
as usual, by means of the ST; 2) without requesting, by means of IS-IS.
This makes things worse. 
This is in fact what Rbridges for now describes as a concept and is a
potential source of problems for convergence. You mentioned that some
people are working on ways to reduce the need for flooding. Can you
please point out some sources?

Regards,
Rute