Subject: [rbridge] Summary of layer 2 multicast stuff

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Sun, 07 May 2006 21:26:44 -0700

Well, there's been a bunch of emails, so this is my attempt to summarize 
the general consensus.

1) RBridges will advertise layer 2 multicast addresses (rather than IPv4 
or IPv6 multicast addresses
to which those l2 multicasts derive)

2) It's pretty clear we know how to do IPv4 multicasts. Since all IPv4 
multicast endnodes do IGMP,
and since the derived l2 multicasts are "owned" by IETF, we don't have 
to worry about any other
applications that don't do IGMP using these addresses, so it is safe to 
optimize the flooding (send
only to links that have a multicast router and/or an endnode that has 
announced through IGMP
it wants to receive the multicast.

3) Optimizing IPv4 multicast will be a MUST for RBridges

4) IPv6 multicasts are more problematic, if it's really true that other 
applications might use those
l2 addresses. (how big a block of the locally derived addresses is IPv6 
using? Why are they
using locally derived addresses?) There are several options for how we 
deal with this:
a) don't optimize IPv6 multicast flooding
b) ignore the possibility of other applications using those l2 multicast 
addresses...those other applications
should know that IPv6 are using those addresses, so even though it's not 
"owned" by IETF, other
applications should design around them, and if things are flaky for them 
as a result (because RBridges
will not deliver a frame addressed to one of those addresses unless 
there is an IPv6 multicast router
and/or an IGMP report received)
c) do flooding optimization for the IPv6 block only if the Ethertype on 
the inside packet indicates
it is an IPv6 packet

5) l2 multicasts that aren't IP...since there is no universally deployed 
"wish to receive" for these
multicast addresses, I see no choice for RBridges than to not attempt to 
optimize for these
addresses (i.e., send these everywhere). Conceivably in the future there 
might be some application
that gets deployed where all endnodes announce somehow, but given that 
current RBridges can't
be designed to recognize that future application, I don't see how we can 
design to optimize those.
My guess is that any high volume multicast applications will just do it 
with IP rather than
inventing their own mechanism.

Radia

---

From: riw at cisco.com (Russ White)
Date: Mon, 08 May 2006 09:49:55 -0400

> 1) RBridges will advertise layer 2 multicast addresses (rather than
> IPv4 or IPv6 multicast addresses to which those l2 multicasts derive)
> 
> 
> 2) It's pretty clear we know how to do IPv4 multicasts. Since all
> IPv4 multicast endnodes do IGMP, and since the derived l2 multicasts
> are "owned" by IETF, we don't have to worry about any other 
> applications that don't do IGMP using these addresses, so it is safe
> to optimize the flooding (send only to links that have a multicast
> router and/or an endnode that has announced through IGMP it wants to
> receive the multicast.

I would leave the specific mechanism open, while requiring optimization,
and write a separate doc on how to actually do the optimization using
IGMP snooping. Other mechanisms might show up that might be more
efficient/etc., so there's no reason to tie the rbridges docs to one
specific mechanism.

> 3) Optimizing IPv4 multicast will be a MUST for RBridges

Agreed.

> 
> 4) IPv6 multicasts are more problematic, if it's really true that
> other applications might use those l2 addresses. (how big a block of
> the locally derived addresses is IPv6 using? Why are they using
> locally derived addresses?) There are several options for how we deal
> with this: a) don't optimize IPv6 multicast flooding b) ignore the
> possibility of other applications using those l2 multicast 
> addresses...those other applications should know that IPv6 are using
> those addresses, so even though it's not "owned" by IETF, other 
> applications should design around them, and if things are flaky for
> them as a result (because RBridges will not deliver a frame addressed
> to one of those addresses unless there is an IPv6 multicast router 
> and/or an IGMP report received) c) do flooding optimization for the
> IPv6 block only if the Ethertype on the inside packet indicates it is
> an IPv6 packet

Or, make IPv6 optimization optional, and leave it outside the scope of
this doc to discuss possible mechanisms. If we separate this problem
out, we can think about it later, once the base documents are done, and
we might possibly come up with a solution.

> 5) l2 multicasts that aren't IP...since there is no universally
> deployed "wish to receive" for these multicast addresses, I see no
> choice for RBridges than to not attempt to optimize for these 
> addresses (i.e., send these everywhere). Conceivably in the future
> there might be some application that gets deployed where all endnodes
> announce somehow, but given that current RBridges can't be designed
> to recognize that future application, I don't see how we can design
> to optimize those. My guess is that any high volume multicast
> applications will just do it with IP rather than inventing their own
> mechanism.

Agreed.

:-)

Russ

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

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 08 May 2006 09:37:42 -0700

Russ White wrote

>efficient/etc., so there's no reason to tie the rbridges docs to one
I can't imagine new mechanisms happening, and I don't see how it 
simplified anything to make it a separate
document. And although it is "safe" for some inner RBridge not to 
filter, it isn't safe to make it
optional for RBridges
to discover locations of multicastreceivers and announce the
location of them...because filtering RBridges will be assuming that lack
of information about interest on a link means they don't need to forward 
there. So that form of
optimization is not safe to be optional.

>we might possibly come up with a solution.
As above, if we make discovery of IPv6 receivers and announcement of 
them optional now, I don't
think it will ever be safe to add it later, since there will be some 
RBridges that would not recognize
whatever the announcement is, and would not advertise it, so future 
RBridges would not be able
to assume it is safe to deliver to a link that they don't know for 
certain does NOT have listeners.
I suspect that sentence has too many negatives to parse, but I hope I 
got the parity right.

Radia

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Mon, 08 May 2006 13:28:32 -0700

> the inside packet indicates

This is an issue for IGMP/MLD snooping in general, hence there isn't 
anything specific to rbridges here. I don't know if there is any work on 
the IGMP/MLD snooping document going on in Magma. Perhaps Dino knows.

> inventing their own mechanism.

Agree in principle.

But there is an architectural issue about the placement of the learning 
of multicast membership that I think we should discuss: Is this 
(IGMP/MLD snooping and potentially future different ways) something 
which only the edge rbridges do, and then they propagate what they've 
learned as some link-state advertisements to the other rbridges, *or* is 
it something that we expect all the rbridges to do?

(One can draw parallels between this multicast issue and the unicast 
issue of whether or not we limit learning of station MAC addresses to 
the edge rbridges.)

*If* the multicast learning is limited to the edge rbridge, it might be 
more feasible to introduce some new multicast learning approach.

    Erik