[trill] ESADI 4. Multiple attachment of the same MAC

[Donald Eastlake <[e-mail]>]

Notwithstanding the claim that there were three suggested changes to
ESADI below is a forth :-)

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]


Update RFC 6325 by updating the last sentence of the last paragraph of
Section 4.2 as shown below to provide better traffic spreading while
avoiding possible address flip-flopping. (The preceding two sentences
are also shown for context.)

   Explanation: Assume some end station has two or more ports with the
   same MAC&VLAN that are each connected to different RBridges (RB1,
   RB2, ...).  With ESADI, some other RBridge, RB0, can persistently
   see that MAC&VLAN connected to multile RBridges. When RB0 ingresses
   a frame for that MAC&VLAN, the current RFC 6325 text permits a wide
   range of behavior. In particular, it would permit RB0 to use some
   rule such as always send to the egress with the lowest System ID,
   which would put all of this traffic through one of the egress RBs
   and one of the end station ports.  There would be no load spreading
   even if there were multiple different ingress RBridges and/or
   different MAC addresses. It also would also permit RB0 to send
   different traffic to different egresses by doing ECMP at a flow
   levee which would likely result in return traffic to RB0 from RB1,
   RB2, ... for the same MAC&VLAN. The resulting address flip-flopping
   could cause problems. The change below fixes this by requiring RB0
   to use only one egress for a particular MAC&VLAN but to select that
   egress pseudo-randomly based on the topology including MAC
   reachabilty.  Assuming multiple ingress RBridges and/or multiple
   MAC addresses, this should result in load spreading without without
   address flip-floping.

OLD: ...  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 decapsulated 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 suggested 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
      network problem since transit RBridges do not examine the
      Inner.MacDA for known unicast frames.

NEW: ...  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 decapsulated 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 then RB2
      MUST, in a pseudo-random way [RFC4086], select one of the egress
      RBridges to which the destination MAC appears to be attached and
      send all traffic for the destination MAC and VLAN to that
      egress. Such pseudo-random selection will, over a population of
      ingress RBridges, probabilistically spread traffic over the
      possible egress RBridges. Reasonable inputs to the pseudo-random
      selection are the ingress RBridge System ID and/or nickname, the
      VLAN, the destination MAC address, and a vector of the RBridges
      with connectivity to that MAC and VLAN. There is no need for
      different RBridges to use the same pseudo-random function.