[rbridge] AF change handling

Fri May 30 14:11:15 PDT 2008

Hi Suresh,

Thanks for brining this up. I don't think there is any way of doing this
perfectly. You have your choice in a space of frames being black-holed,
addresses being unnecessarily forgotten, or scaling problems. 

Of course, you can always use the explicit end station address
distribution instances of TRILL IS-IS to fix this. Also it is not a
problem for multi-destination frames as, if necessary, the VLAN pruning
of distribution trees will be adjusted automatically. It might be a good
idea to add a specific provision that if Rbridge-A ceases to be an
appointed forwarder for VLAN-x for any ports, which is all you can tell
from the link state database currently, then all other Rbridges should
forget any addresses in VLAN-x they have learned from data which point
to Rbridge-A.

However, all that still does not address the worst case where Rbridge-A
ceases to be an appointed forwarder for VLAN-x on one or more of its
ports while remaining an appointed forwarder for that VLAN on one or
more other port.

One way to "fix" that, to the extent that bridges do, would be to have
an optional explicit topology change message to advise other Rbridges
that they should forget (or at least reduce their cache timer) any
addresses learned from data for the source Rbridge of the topology
change message. This message could be per VLAN or could have the VLANs
affected encoded in it...

Another possibility would be for an Rbridge to send out amnesia frames
listing the addresses it has learned locally on that port that the VLAN
that it is no longer going to be appointed forwarder for, telling other
Rbridges to forget those specific addresses for that VLAN... This would
probably work for modest numbers of addresses but that won't help if the
source Rbridge had suffered from cache overflow and might result in a
big burst of traffic if a lot of addresses are send out on a appointed
forwarder status change.

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.

If we had implemented the Port ID feature suggested by Silvano in the
base protocol, that would provide a way to send out a port specific
topology change message, as opposed to having to do things a the
granularity of Rbridges. (This feature is currently described in
draft-eastlake-trill-rbridge-options-00.txt.)

I suppose if we need to address this in the base protocol, right now I'd
favor the link state database technique described above.

Thanks,
Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Suresh Boddapati
Sent: Thursday, May 29, 2008 5:43 PM
To: rbridge at postel.org
Subject: [rbridge] AF change handling

I think there is a problem wrt handling the change in
AF status.

Consider the following example:

- A is an RBridge with two ports P1, P2 and P3 (all in
the same inner VLAN X). It does not have any
adjacencies on P1 and P2 so it ends up being the AF
for VLAN X on P1 and P2. P3 leads to the TRILL cloud.
- There is a host H1 in VLAN X connected to port P1 of
A.
- R is a remote RBridge connected to a host H2 in VLAN
X on one of its ports.

When H2 sends a frame for H1, through the learning
mechanism, R associates H1 with RBridge A.
Subsequently, R will TRILL Unicast all frames destined
for H1 to A. So far so good.

Now assume that a new RBridge B comes up on the
segment connected to P1 and becomes the DRB and
appoints itself as the AF for VLAN X on that port. So
A is no longer the AF for VLAN X on P1. Per the spec,
nothing happens at this point.

Frames sent by H2 to H1 will continue to be sent to A
by R, but A can no longer decapsulate and put them on
P1, since it is not the AF. What is A to do? 

This is similar to the recently discussed issue of
sending BPDU with TCN flag set when AF changes so that
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
desirable to flush all MACs associated with A just
because its AF status changed on one of its ports. It
may still be AF on other ports (in this example, A is
still AF for VLAN X on P2 and there may be a lot of
conversations active on that port, and all those MAC
addresses will get flushed unnecessarily).

Thanks,

Suresh

_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge