Subject: [rbridge] AF change handling

From: "Ravi Shekhar" <[email-masked]>
Date: Mon, 2 Jun 2008 20:11:13 -0700

>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
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Mon, 2 Jun 2008 23:50:16 -0400

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Ravi Shekhar
Sent: Monday, June 02, 2008 11:11 PM
To: [email-masked]
Subject: [rbridge] AF change handling

addresses

- Ravi Shekhar.

---

From: James Carlson <[email-masked]>
Date: Tue, 3 Jun 2008 07:13:07 -0400

> is too small to bother with.

In some cases, "flaps" are actually changes in attachment -- i.e.,
someone moving patch cables around -- and I'm not so sure I'd want to
try to optimize that one away.  Catching the event does sound good
enough to me.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Tue, 3 Jun 2008 11:40:42 -0400

That's a good point.
Donald

---

From: Suresh Boddapati <[email-masked]>
Date: Tue, 3 Jun 2008 09:49:41 -0700 (PDT)

> Recipients can "optionally" process the AF-gen-id

I like this idea. This can be optimized a bit to
change the gen-ID only when the RBridge moves from AF
to non-AF on any of its ports. When an RBridge changes
from non-AF to AF on any of its ports, nothing needs
to be done, since there are no MAC addresses to
unlearn. So maybe you could call this "AF-lost-GenID"
or "AF-lost-counter". 

Suresh

---

From: Dinesh G Dutt <[email-masked]>
Date: Tue, 03 Jun 2008 10:29:43 -0700

I like this idea,

Dinesh
Ravi Shekhar wrote:
> >know it could forget or shorten the cache timer for all VLAN-x addresses
> 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.
>
> ------------------------------------------------------------------------
>

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