[rbridge] AF change handling

[Dinesh G Dutt]

I like this idea,

Dinesh
Ravi Shekhar wrote:
> >To avoid extra messages and do this via the link state data base, you
> >would need some additional encoding. I don't see how just some one bit
> >flag per Rbridge per VLAN would do it as you can never tell that any
> >particular Rbridge will see each successive update from any other
> >Rbridge, as far as I know. It might see update N and N+k but never see
> >N+1 through N+k-1 and the bit might have flipped twice over that
> >sequence. So I think you would have to do something which was logically
> >equivalent to the following: include in the link state data base for
> >each Rbridge a hash function of the ports for which it is appointed
> >forwarder for VLAN-x. For example, SHA-1 of the sorted MAC addresses of
> >all the ports which are appointed forwarders for VLAN-x. Then, when
> >Rbridge-1 notices this hash change for Rbridge-2 for VLAN-x, it would
> >know it could forget or shorten the cache timer for all VLAN-x addresses
> >that it learned for data from Rbridge-2.
>  
>  
> Donald, can it simplified to have an “optional” TLV per VLAN-x that contains
> the “AF-gen-id” of that RBridge? Each time AFness of an RBridge changes for VLAN-x
> on any of its port, it can increase its AF-gen-id by 1 for that VLAN-x in its LSP. 
> Recipients can “optionally” process the AF-gen-id TLV to shorten the cache timer 
> as you have stated.
>  
> - Ravi Shekhar.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan