Subject: [rbridge] Queries on suspended state

From: somnath chatterjee <[email-masked]>
Date: Tue, 6 Dec 2011 14:11:15 +0530

Hi Authors,

For devices which implements TRILL and which uses same MAC for all
their ports, if two or more ports of this device are connected to same
link all but one port go in suspended state  based on priorities
received in Hellos as per TRILL RFCs. Why is this required when RBs
can easily distinguish between its own ports and other devices ports
connected on the link. If suspension was not there DRB could delegate
some of its work like appointing AF for vlans on its other port(s)
having same MAC.

Another very basic question is I am unable to understand the advantage
of suspended state with respect to MAC collision with the port of
other RB as system-id can help to identify the ports.

Thank you,
Regards,
Somnath.
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 6 Dec 2011 09:25:03 -0500

Hi Somnath,

As explained below, the reason for suspending all but one port on a
link with a particular MAC address is to stop unicast traffic from
getting duplicated.

> other RB as system-id can help to identify the ports.

Hopefully same MAC address ports on a link is a rare situation. But,
yes, RBridges can tell all these same MAC address ports apart based on
System ID and Port ID. But these identifiers do not occur in TRILL
Data frames or in the TRILL Neighbor TLV. If you had two or more ports
with the same MAC address on an Ethernet link, maybe multi-destination
TRILL data frames would work, since they are multicast and, if
necessary, sorted out by the reverse path forwarding check. But if you
had two or more active ports with the same MAC address they would all
pick up known unicast (M=0) TRILL Data frames resulting in multiple
copies of the frame. In addition, the existing IS-IS TRILL Neighbor
TLV can only indicate Hello visibility by MAC address. It would have
to be expanded to list the System ID and Port ID for each seen
neighbor. And it is possible that there would be additional problems
that don't occur to me right now.

Trying to relax this suspended port logic, even if only on access
links, would make the specifications significantly more complex and
fragile.

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

---

From: Radia Perlman <[email-masked]>
Date: Tue, 6 Dec 2011 10:30:42 -0800

Interesting point, Somnath.

Hopefully the case of multiple ports with the same MAC address is rare and
it's not a priority to eke every bit of multipathing capability out of it.

It's possible that if RBx has multiple ports on the same link, all using
the same MAC address, that native frames would work properly...as you said,
RBx just needs to make sure that the different ports handle different
VLANs. Though as Donald said, it's not clear what RBx should do when "RBx"
is specified (in the outer header) as the next hop for an
already-encapsulated known-unicast.  Perhaps RBx could look inside the
packet to see the VLAN on the inner header to decide which of its ports
should pick up the packet, but other than this, there would be no need to
look beyond the TRILL header when forwarding known unicast.

But I guess the WG just decided we wanted to make sure this case (using the
same MAC address on mulltiple links) didn't break anything, and I don't
think people were excited about encouraging use of same MAC on different
ports.

Radia