[rbridge] AF change handling

[James Carlson]

Suresh Boddapati writes:
> the "local" bridges can clear their cache. One option
> is for A to send something similar in its LSP.  If A
> sends something saying "My AF state changed for this
> VLAN on one of my ports", and all RBridges flush all
> the MACs they had associated with A, it would work,
> but this has scale implications. It may not be

I agree that we need either a flush mechanism or some sort of a
redirection.  But I disagree on the severity of the issue: all that's
necessary is that we make DRB selection intentionally stable so that A
doesn't _want_ to give up its AF state on that port when B switches
on.

If you make the change sufficiently unlikely, then the effects of it
are much less interesting.  Letting administrators know that they can
hurt themselves by toying with priority is probably the right answer.

As for mitigating the problem, the active DRB switch-over case you
mention is actually the simple one.  The harder one is the case where
A is disconnected from a few networks where it was the DRB, some small
time period elapses, and then B starts up on the networks A has left.

In the active switch case, the routers involved "know" who the players
are and could (presumably) arrange to have some sort of summary
information distributed after the DRB election dust settles.  In the
blind case, nobody has any clue what's just happened.  As far as A
knows, the links are just disconnected.  As far as B knows, he's the
first RBridge to enter the room.  Neither knows about the other.

One way to deal with this would be to have an RBridge that either
loses its established DRB status on a port or has a port
administratively shut down (or hardware failure) withdraw its nickname
and then reinsert.  Nickname withdrawl already has to cause a flush of
the forwarding entries that map to that nickname.

A sufficiently clever implementation that has zillions of ports and is
concerned about having to flush on each port shut down could
presumably run multiple instances, use multiple nicknames, and split
the ports over the nicknames.  When you get down to a 1-to-1 mapping
of nicknames to ports, the flush-related overhead is minimized -- at
the cost of extra LSPs and nickname exhaustion.  Somewhere in the
middle is a happy medium.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
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