[rbridge] AF change handling

[Radia Perlman]

Yes. What you're saying is correct. If on a layer 2 cloud, the appointed 
forwarder changes from being R1 to R2, then
all the remote RBridges that think R1 is the proper egress RBridge for 
all the endnodes on that cloud will be
sending traffic for those hosts to the wrong RBridge.

I'm not sure what can be done about that. Eventually these host entries 
will time out.
We could do something like what you suggest, namely, having R1 (when it 
is no longer appointed forwarder on one of
its links) send a multicast advisory message saying "use a short cache 
timer for all my VLAN X endnodes because I am no longer
appointed forwarder on one of my links". Perhaps this advisory message 
could even list some (or all, if they fit) of the MAC addresses
that were on that link.

This seems like it might be a good idea. It would be a MAY or SHOULD to 
send such a message.
It would be a MAY or SHOULD to look at the message.
It would be sent as a VLAN X multicast, so it would only be looked at by 
VLAN X forwarders on all the links.
We'd have to define a format for it.

Radia



Suresh Boddapati wrote:
> 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
>