[rbridge] AF change handling

[Eastlake III Donald-LDE008]

That would work but not be quite as good because if the AF status of a
port flapped (changed and then changed back to its original state
quickly), it would not generate the same value. But maybe that advantage
is too small to bother with.
 
Donald

________________________________

From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Ravi Shekhar
Sent: Monday, June 02, 2008 11:11 PM
To: rbridge at postel.org
Subject: [rbridge] AF change handling


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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20080602/8fd6d804/attachment.html