Subject: Re: [rbridge] Consensus around MGROUP set of PDUs

From: Linda Dunbar <[email-masked]>
Date: Fri, 02 Jul 2010 15:29:15 -0500

Does TRILL have different multicast addresses for different multicast
groups, like IEEE802.1Q does? Why need different PDU for different multicast
groups? 

Regards, Linda Dunbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Erik Nordmark
Sent: Friday, June 04, 2010 11:39 AM
To: Developing a hybrid router/bridge.
Subject: [rbridge] Consensus around MGROUP set of PDUs

Based on the recent discussion on the list, and not having found any
earlier discussion on the MGROUP set of PDUs on the TRILL WG mailing
list, it seems that there was never any TRILL WG discussion and
consensus about the need for or use of separate PDUs for multicast
membership.

The fact that there was some IS-IS WG discussion about this seems
unrelated, since the TRILL WG is the one to decide what they need from
IS-IS. And in the trill-protocol spec we don't specify any need for
additional PDU types for multicast.  In fact the document seems to talk
about TLVs and sub-TLVs in the regular LSP PDU:

4.2.4.4 TRILL LSP Information

    The information items in the TRILL IS-IS LSP that are mentioned
    elsewhere in this document are listed below. Unless an item is stated
    in the list below to be optional, it MUST be included. Other items
    MAY be included unless their inclusion is prohibited elsewhere in
    this document. The actual encoding of this information and the IS-IS
    Type or sub-Type values for any new IS-IS TLV or sub-TLV data
    elements are specified in a separate document [layer2].

Note that for the MTU testing in section 4.3.2 it is clear that the
expectation is that new IS-IS message types are needed.

Hence I conclude that the TRILL WG consensus has been to not require any 
new MGROUP PDU types.

If there is disagreement, or a need to revisit this, then I suggest the
proponents of MGROUP PDUs for TRILL make the case in the TRILL WG why
this would be required for TRILL's use of IS-IS. But that would be a
change from the current TRILL protocol specification.

    Erik

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 2 Jul 2010 17:58:15 -0400

Hi Linda,

> groups, like IEEE802.1Q does? Why need different PDU for different multicast

I'm not sure exactly what you mean. In TRILL, multi-destination data
frames are sent between RBridges encapsulated to the All-RBridges
multicast address (01-80-C2-00-00-40), while data frames with a known
unicast address destination are sent between RBridges encapsulated to
the unicast address of the next hop RBridge.

In order to be able to optimize the distribution of multicast native
frames, RBridges need to know what other RBridges have attached
listeners for particular multicast addresses, so they can prune the
distribution tree. This information is distributed as part of the link
state (along with multicast router attachment information).

Ideas with the MGROUP PDU set were to provide one more set of 256
fragments to accommodate more link state information and to segregate
the probably more rapidly changing multicast listener information
(more rapidly changing than topology); however, there are other
techniques if more fragments are really needed and more rapidly
changing information should be in different fragments anyway so you
don't need a different PDU.

Thanks,
Donald

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 02 Jul 2010 17:15:38 -0500

Donald, 

I mean why doesn't TRILL allow many multicast addresses, like
01-80-C2-00-00-4x, where x can be 0~F, with each address represents one
multicast domain? 

Or even 01-80-C2-00-00-xx, where you can have 256 multicast addresses,
representing 256 multicast groups. There are plenty of multicast addresses
to use. Using different multicast addresses to represent different multicast
groups have worked very well in Ethernet networks. 

Linda Dunbar

-----Original Message-----
From: Donald Eastlake [mailto:[email-masked]] 
Sent: Friday, July 02, 2010 4:58 PM
To: Linda Dunbar
Cc: Erik Nordmark; Developing a hybrid router/bridge.
Subject: Re: [rbridge] Consensus around MGROUP set of PDUs

Hi Linda,

Thanks,
Donald

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 2 Jul 2010 18:08:04 -0700

Hi Linda,

MGROUP PDU is control-plane related and not data-plane and thus no
correlation to the need for additional L2 mcast group addresses.

Cheers,
Ali 

> Behalf Of Linda Dunbar
> Sent: Friday, July 02, 2010 3:16 PM
> To: 'Donald Eastlake'
> Cc: 'Developing a hybrid router/bridge.'

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 2 Jul 2010 21:23:40 -0400

Hi Linda,

> groups have worked very well in Ethernet networks.

Well, the original destination MAC address of a data frame, unicast,
multicast, broadcast, whatever, is preserved inside the TRILL
encapsulation and becomes the actual destination MAC again when the
encapsulation is removed and the data frame delivered to its
destination or destinations. So what we are talking about here is just
the destination address used on the outside when a TRILL encapsulated
data frame is sent from one RBridge to the next hop RBridge or
RBridges.

Consider a simple case where all RBridges in the campus are directly
connected by point-to-point physical links. In that case, If RBridge
RB1 is forwarding a frame, all it has to do is pick the right port to
send it out of (or ports if it is a multi-destination frame and RB1 is
at a fork in the distribution tree). Since RBridges, like any router,
swap the outer header for a new outer header each hop, in theory, RB1
could send such frames out the port (or ports) it needs to, in this
point-to-point case, with any destination MAC address that the next
hop RBridge would accept: the unicast MAC address of the next hop
RBridge, any multicast address the next hop RBridge would accept, or
even the broadcast MAC address. The next hop RBridge will,
effectively, discard the outer link header (for Ethernet: Outer.MacDA,
Outer.MacSA, possibly a VLAN tag) on receipt of the frame and add a
new outer link header appropriate for whatever link it is sent on when
it forwards the frame. (I realize that the way many switches are
designed, it could be a problem to handle a multi-destination frame
recieved unicast or a single destination frame received broadcast,
etc.)

OK, now consider the more general case where the ports of an RBridge
are connected to multiple other RBridges via multi-access links. These
could be true mult-access media or could actually be fairly arbitrary
bridged LANs made from customer 802.1Q or 802.1D bridges or a mixture
of all these.
       For a unicast known destination frame, RB1 only wants to
forward it to a single next hop RBridge, so it forwards it out one
port and the outer header it adds before forwarding has the unicast
address of the desired next hop RBridge. If such a frame was forwarded
with a multicast or broadcast outer header destination address, in
this general multi-access case, it would be received by multiple
RBridges and you would need additional complexity and risk of
duplication or loss to be sure that one and only one of these multiple
RBridges accepted the frame.
       For a multi-destinaton frame, of course, RB1 may need to
forward the frame out more than one port. Looking at any of those
ports, it may need to forward the frame to more than one next hop
RBridge connected to the multi-access link out that port. Clearly it
can't use a unicast outer address. If the multi-access link is a
bridged LAN, the bridged LAN might deliver it to only one of the
RBridges attached to that link. On the other hand, broadcast is
overkill, delivering the frame to and potentially interrupting every
connected end station. So, multicast seems like the way to go. But
remember, this outer address is just to deliver the frame to the
potential next hop RBridges. Using just one All-RBridges address is
the simplest and easiest thing to do. Let's say that out the port of
interest on RB1 there is a bridged LAN that also connects to RB2, RB3,
RB4, and RB5. Seems like about the only useful thing you could use
different outer multicast addresses for on the frames sent into this
multi-access ink by RB1 would be to selected different subsets of the
connected RBridges. Since there are really 5 RBridges connected to
this link (RB1-RB5), you would need 31 multicast addresses to select
different non-empty sub-sets. But you would need a complex local
protocol to assign multicast addresses to the different subsets with
stability and settling time questions as RBridges attach and detach
from the link... Basically, the TRILL WG decided to go the simple
path, which seems the most practical, and uses only a single multicast
address for this purpose.
      (There were a few versions of the TRILL base protocol draft that
permitted the unicast forwarding of multi-destination frames in the
case where there was exactly one next hop RBridge out a port. However,
this was rejected as hard to implement with some hardware. It would be
possible to add this as an option that could be used only when the
next hop RBridge indicates it is willing to accept multi-destination
frames that are unicast encapsulated.)

Thanks,
Donald