[rbridge] Proposed compromise for short/long hellos

[Don Fedyk]

Hi Ali 

> -----Original Message-----
> From: Ali Sajassi (sajassi) [mailto:sajassi at cisco.com] 
> Sent: Thursday, March 26, 2009 1:09 PM
> To: Fedyk, Don (BL60:1A00); Anoop Ghanwani; Radia Perlman
> Cc: TRILL/RBridge Working Group
> Subject: RE: [rbridge] Proposed compromise for short/long hellos
> 
> 
> 
> Don,
> 
> As we have discussed, there are two issues in here related to this
> corner case (legacy hubs between Rbridges): a) possibility of 
> loop when
> hello get discarded by interim hubs and b) black holing of data when
> there is no MTU negotiation. 

IS-IS does not support MTU negotiation.  The MTU is set and is
essentially must be the same everywhere.  There is some tolerance to
accepting larger messages (less than MTU) but the recommendation is any
node that cannot support the MTU the adjacency is lost. 
See
http://www.ietf.org/mail-archive/web/isis-update/current/msg00072.html 

If you wish to learn of RBridges by some other protocol/means and then
use IS-IS with all the same MTU then that would be OK.  But the proposal
to change IS-IS Hello messages changes IS-IS to a behavior it does not
support.  The reason is other bridges with larger MTU may have sent LSP
that cannot be exchanged on a lower MTU link. This is not like your PC
where you just negotiate a lower MTU. You have to change the whole
network or get rid of the MTU restriction.   

And then you have the question of what do you do when you are and
RBridge that cannot talk to another RBridge using IS-IS because but you
know it is out there?     I say for this case you must fall back to a
bridge compatible mode of operation for the portion of the spanning tree
that connects the adjacency.  

So to be clear the least you can do is:
1) Detect a lower MTU by some means. (MTU lower than the globally set
IS-IS configuration.) 
2) You cannot adapt a single RBridge to a lower MTU. (Within the current
IS-IS design over layer 2) 
3) And you need to take some action because you have to ensure that the
RBridges that know about each other but cannot exchange topology do not
mess up what they send. <- This peice is essential IMO. 

Regards,
Don
 

> 
> Both of these issues can be addressed by the initial proposal on this
> thread using a single hello type and then have a MTU 
> discovery exchange.

No see above.
> So, if it can be addressed easily like that, then one would wonder why
> to make the life more complicated and talk about introducing 
> STP bridge
> protocol.

No see above.
> 
>  
> > 
> > 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.
> > 
> 
> The difference is that in case of 802.1aq as you know, the 
> .1aq bridges
> don't need interoperate over legacy bridges/switches (for optimum
> forwarding). So, they don't from adjacencies and don't 
> forward traffic.
What 802.1aq does is form a Shortest Path Tree region dynamically. The
Region does not include legacy bridges but it forwards over them like a
VLAN Bridge. Two SPT reqions will forward traffic over a legacy Bridge.


> Whereas, in here, the interoperability over legacy LAN is of interest.
The difference is that Trill performs its adjacency over the legacy LAN.
(BTW .1aq can do this as well if we include shared interfaces but the
difference would be that the data plane would use VLAN translation to
the STP (or B-VLAN translation to the STP) at the legacy interfaces.
Trill uses an encapsualtion that is the difference.

Regards,
Don 
> 
> Cheers,
> Ali
> 
>