Subject: [rbridge] Some corner cases related to ambiguous destinations

From: Donald Eastlake <[email-masked]>
Date: Tue, 29 Sep 2009 23:52:35 -0400

A couple of corner cases have been noticed related to ambiguous
destinations. In particular multiple RBridges could, as a transient
condition, have the same nickname. In addition, it is possible,
through manual configuration, layer 2 registration protocols, and/or
ESADI to end up with the same destination MAC address in the same VLAN
on two or more links.

The text as the bottom of this message is suggested as a new
subsection of the base protocol draft to take care of this where the
ambiguous destinations are at different RBridges. It is also possible
for duplicate MAC addresses in the same VLAN to be on links for which
a single RBridge is the appointed forwarder. To take care of this, a
few words can be added to section 4.6.2.4 saying that if the egress
RBridge believes that the destination MAC address in the right VLAN is
on two or more links for which it is appointed forwarder with the same
confidence, it sends the frame to all those links.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

4.2.6 Shortest Path Computation, Forwarding, and Ambiguous Destinations

This section describes the logical result desired. Alternative
implementation methods may be used as long as they producing the same
forwarding behavior.

When building a forwarding table, an RBridge R1 calculates shortest
paths from itself as described in [RFC1195] Appendix C.1. Nicknames
are added into the shortest path calculation as a final step, just as
with an endnode. If multiple RBridges , say Ra and Rb, claim the same
nickname, this is a transitory condition and one of Ra or Rb will
defer and choose a new nickname. However, R1 simply adds that nickname
as if it were attached to both Ra and Rb, and uses the standard
shortest path calculation to choose the next hop

An ingress RBridge RB2 maps a native frame's known unicast destination
MAC address and VLAN into an egress RBridge nickname. If RB2 learns
addresses only from the observation of received and decapsulated
frames, then such MAC addresses cannot be duplicated within a VLAN in
RB2 tables because more recent learned information, if of a higher or
equal confidence, overwrites previous information. However, duplicates
of the same MAC within a VLAN can appear in ESADI data and between
ESADI data and addresses learned from the observation of received and
decapulsated frames, entered by manual configuration, or learned
through layer 2 registration protocols. If duplicate MAC addresses
occur within a VLAN, RB2 sends frames to the MAC with the highest
confidence. If confidences are also tied between the duplicates, for
consistency it is sugested that RB2 direct all such frames (or all
such frames in the same ECMP flow) toward the same egress RBridge;
however, the use of other policies will not cause a problem since
transit RBridges do not examine the Inner.MacDA for known unicast
frames.
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge