[rbridge] Proposed compromise for short/long hellos

[Don Fedyk]

Hi Anoop 

> -----Original Message-----
> From: Anoop Ghanwani [mailto:anoop at brocade.com] 
> 
<snip>
> I think he's referring to one of the options
> discussed which was to have a big spanning tree
> that spanned the entire TRILL campus and all of the
> bridge islands that might need to be interconnected
> by TRILL.  
> 
> (Don, please clarify if I am misrepresenting
> what you wanted to say.)

First I want to point out this is supposed to be an exception. MTUs
don't change by themselves but you may find you plug in some equipment
where you have an MTU problem. 

I'm thinking that Shortest Path Bridging can handle this on a neighbor
basis so why can't RBridge? Perhaps we should list the cases this is an
issue. James' (Jim's) example was rather straight forward and I could
not see why RBridge would not behave like a bridge.  But then you have a
LAN with some RBridges and some Bridges and I can't say I know all the
permutations.

Does this create a big bridged network? That was not my intention but
RBridges do link multiple spanning trees and there is a perhaps a danger
defaulting to anything other than a stub on a link if there is a
problem. 

Aside speaking with Radia it occurred to me Radia's proposals were to
adapt to smaller MTU on a link.  I believe you may be able to engineer a
network to a lower (or larger) MTU size but my understanding is all
IS-IS routers are expected to have the same ReceiveLSPBufferSize which
must be lower or equal than MTU anywhere which means adapting on the fly
for a specific link is probably not a good idea. So I'm not comfortable
with changing the way MTUs 

I found this thread on the subject.    
http://www.ietf.org/mail-archive/web/isis-update/current/msg00072.html

Regards,
Don 


> 
> However, I disagree that that is a good approach
> because we will be stuck with dealing with STP 
> convergence times before we can do anything useful
> in the TRILL network.  STP can be very fast when
> the network is small and failures are fairly localized,
> but it gets worse as the network gets bigger.
> 
  

> Anoop
>