[rbridge] Proposed compromise for short/long hellos

[Radia Perlman]

I assume what you mean by "changing IS-IS" is the phrase "MUST NOT" pad 
hellos?
Or are you talking about adding a bit "I support the (to be specified) 
MTU discovery protocol"?
(or both perhaps).

Anyway, when you say "as was pointed out by James", I don't remember 
what comment you are
referring to, not sure which "James" we are talking about (James 
Carlson?) and don't know what
it means to "default to STP behavior". So can you just be specific about 
the protocol behavior you
are proposing, without referring to other things?

One thing you might be referring to is a proposal that I liked, and was 
in some version of the spec, but
got shot down by the WG (not sure I remember why), which is that the DRB 
election be the
spanning tree election, and you are DRB if and only if you manage to 
become root of the bridge
spanning tree. But that got shot down, and there would have needed to be 
another type of hello
anyway in order to do the IS-IS stuff, like giving the pseudonode a name.

But mostly, I just didn't understand your message...

Thanks,

Radia


Don Fedyk wrote:
> Hi Radia
>
> I'm still not convinced you should be changing IS-IS.  
>
> The root cause of the issue is RBridge forms adjacencies on links with
> non direct neighbors. It also make forwarding assumptions when it does
> not detect neighbors.  
>
> This is different behavior from every other system that I know of.  
>
> If RBridge defaulted to STP behavior as was pointed out by James then no
> modification to IS-IS would be needed plus the issue of looping packets
> would be nipped in the bud.  You solution below only detect the problem
> you still need to assume an appropriate forwarding behavior and this is
> STP as a default. 
>
> Regards,
> Don   
>
>
>
> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
> Behalf Of Radia Perlman
> Sent: Wednesday, March 25, 2009 12:58 PM
> To: TRILL/RBridge Working Group
> Subject: [rbridge] Proposed compromise for short/long hellos
>
> After listening to the discussion at the meeting, and talking to some 
> people in the hall, I hope
> this might be palatable to everyone.
>
> a) have only one type of Hello: the original type, but say in the spec 
> that Hellos
> MUST NOT be padded. Also mention a maximum size, and say that this might
> limit really really really creative appointments of lots of appointed 
> forwarders for lots
> of VLANs.
>
> b) have another type of mechanism, perhaps called "MTU discovery", which
>
> would
> be a pairwise protocol between two RBridges R1 and R2, where R1 sends a 
> padded
> message, and R2 acks it if R2 received it. This would be an optional 
> protocol specified
> in a separate document
>
> c) we'd add a bit to the Hello saying "I support the MTU discovery
> protocol"
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>