Subject: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 3 May 2006 11:19:08 -0400

Radia,

	Please see below... 

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
--> Sent: Wednesday, May 03, 2006 2:13 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Should layer 2 or layer 3 IP 
--> Multicast addresses be advertised?
--> 
--> Tim,
--> 
--> There isn't a problem. There's a block of layer 2 multicast 
--> addresses derived from IP multicast addresses. These are the 
--> only multicast addresses that RBridges are attempting to 
--> optimize delivery of.
--> 
--> Other layer 2 multicast addresses just get delivered to all 
--> links, like bridges would do.
--> 

This is the assumption that bothers me.  Tim is correct in his
comment that there may be other mechanisms for advertising any
interest in MAC multicast addresses - besides IGMP.

Currently, we can feel relatively certain that either this is
the only case that exists, or the only case that we care about
in this context.  However, this is hardly a "future-proof" way
of doing architectural design.

That is why - from an architectural perspective - we should 
assume that an egress RBridge "figures out" what MAC multicast
addresses it should announce interest in "somehow" and then it
advertises interest in those MAC multicast addresses to other
RBridges.  The one example we can point to today would be as a 
result of using IGMP snooping (and we should mention that), but 
we should not assume that will be the only way this will ever 
happen.

The main issue in this entire context is that we are assuming
that we can know for sure that nobody uses multicast addresses
in the range that is used for IP multicast to MAC mapping unless
they are in fact using it for IP multicast and using IGMP to do
this.  We are also implicitly assuming that there are no other
well-known MAC multicast addresses or address ranges.

These are fair assumptions, at this time.  In fact, I would go a
bit further and speculate that nobody is using any MAC multicast
address except in a relatively small set of well-known multicast
addresses and address ranges - including the IP multicast MAC
multicast address range.  

The reason why I strongly suspect this is because applications 
that might use multicast will do one of the following:

1) Use well-known multicast MAC addresses that are know to work
   and be supported by all existing L2 (and below) forwarding 
   devices,
2) Have a mechanism for negotiating and communicating multicast
   MAC usage,
3) Rely on the fact that multicast addressed frames are in fact 
   treated as broadcast frames, or
4) Use the all-ones broadcast address instead.

In general, if the application relies on broadcast-like frame
distribution, it almost certainly uses the all-ones broadcast 
MAC address.  This seems obvious because the only result that
appears to have come out of deployment of switches that don't 
"broadcast" multicast frames has been work to make sure that
they do forward them in the limited set of specific cases that
apply today (i.e. - IP multicast in particular).

The obvious corrolary to this is that any application that uses
a MAC multicast address assumes that there is some potential for
benefits from less-than-broadcast, domain-wide, distribution of
MAC multicast frames.  Clearly this implies development of some
mechanism(s) to support limited distribution (e.g. - IGMP snooping).

--
Eric

--- [SNIP] ---

---

From: riw at cisco.com (Russ White)
Date: Thu, 04 May 2006 08:54:26 -0400

> we should not assume that will be the only way this will ever 

I don't know if I understand this, actually.... Today, what happens is
we get layer 2 multicast, and forward it everywhere. We use IGMP
snooping to optimized that flooding, on the assumption that anything
being sent to a layer 2 multicast address that maps to a layer 3
multicast address must be an IP originated multicast (as it should be,
based on the mapping rules), and thus, we can optimize these multicasts
based on the layer 3 information.

So, in light of this, shouldn't an rbridge just act the same way? In the
absence of other information, we should flood multicast through the
vlan. IGMP snooping and "other mechanisms" MAY be used to optimize the
tree, but we can't count on these. They are good optimizations, and we
should use them if we have them, but we probably shouldn't specify the
mechanism used to discover the layer 3 multicast topology, I wouldn't
think (?).

Hmmm.... I wonder if we should:

- -- Require optimization of the tree when layer 3 information allowing
the optimization of the tree is available.

- -- Allow the use of IGMP snooping to provide such learning of layer 3
information.

- -- Put it on the agenda to talk about using other, rbridge specific,
mechanisms to find this sort of information. For instance, we could
postulate a mechanism where we do conflate l2 and l3 addresses in
rbridge advertisements, and build an l3 tree for multicast in parallel
with the l2 tree, restricting the l2 tree based on the l3 tree.

While we don't have consensus on such things right this moment, writing
the current drafts such that some future mechanism could be devised
appears to be the best strategy.

:-)

Russ

- --
riw at cisco.com CCIE <>< Grace Alone

---

From: dino at cisco.com (Dino Farinacci)
Date: Thu, 4 May 2006 17:10:56 -0700

>> based on the layer 3 information.

    The optimization is not based on a L3 multicast address mapping to a L2
    multicast address but the fact there is receiver membership signalling.
 
    If L2 apps implemented GMRP/GARP, we could optimize for non-IP multicast
    as well.

>> tree, but we can't count on these. They are good optimizations, and we

    SHOULD or even MUST.

    I wish some enterprise multicast deployers on this list would speak up and
    indicate not doing this optimization is a non-starter. That is what
    they have told me anyways. 

>> with the l2 tree, restricting the l2 tree based on the l3 tree.

    If someone doesn't think this assumption is too restrictive and assumed
    that senders must also be receivers, then the rBridges directly connected
    to the hosts could do the signalling inside of the rBridge network.
   
    This way we don't have to do flooding for non-signaled protocols.

Dino

---

From: dfawcus at cisco.com (Derek Fawcus)
Date: Fri, 5 May 2006 02:13:35 +0100

> addresses and address ranges - including the IP multicast MAC

Well for IPv4 maybe,  but for IPv6 one may have a problem.

IPv6 uses 0x33 0x33;  which (AFAIK) is a local allocation.
So any other application is free to use this range.

So if the rbridge was to try and optimise the sending of packets
to such MAC addresses based upon knowledge gleaned from MLD,  it
would also have to inspect the ethertype of the forwarded packet.

Then only optimise 0x86dd,  while flooding other ethertypes using
a MAC in the 0x33 0x33 range.

DF

---

From: riw at cisco.com (Russ White)
Date: Fri, 05 May 2006 09:27:07 -0400

>     If L2 apps implemented GMRP/GARP, we could optimize for non-IP multicast

Yes, certainly....

>     they have told me anyways. 

I don't mind SHOULD or MUST, at all.

>     This way we don't have to do flooding for non-signaled protocols.

I suppose my main point is that the architecture doc, and most other
docs, could say: "Multicast flooding MUST be optimized to allow
knowledge of receiver group membership to prune the layer 2 flooding
tree calculated by the rbridge." And then leave the specific mechanism
of how this is done to future documents, rather than getting bogged down
in it here.

There are likely to be multiple ways of doing this for each given l3
protocol--IGMP snooping, including l3 membership in the LSPs (probably
the easiest, long term), other forms of snooping, and maybe even ideas
we've not thought of yet. Let's just incubate those ideas in another
doc, perhaps.

:-)

Russ

- --

---

From: dino at cisco.com (Dino Farinacci)
Date: Fri, 5 May 2006 11:56:34 -0700

>> of how this is done to future documents, rather than getting bogged down

    That would be perfect IMO.

Dino