[rbridge] Need help sorting out IP multicast with RBridges

[Radia.Perlman@sun.com]

IP multicast is really hairy. I'd like some opinions on what RBridges should do with multicast, since it was
pointed out to me that what's in the current spec is not optimal. I have 4 orthogonal questions below, numbered
Question 0 through question 3. If you don't understand what I'm saying, ask me to explain.

The current spec says:

a) RBridges discover whether they have IP routers on their own link. Actually what's in the spec for this won't quite
work since I asked what messages IP multicast routers send, and was pointed to a lovely spec (IP multicast router
discovery) but was told at this meeting that it isn't actually implemented. So I'll have to change it to something else.
currently I think the "something else" is "listen to PIM messages". This is ugly, since in theory there could be other
IP multicast protocols.

Question 0: How should RBridges discover which links have IP multicast routers on them?

b) RBridges inform (in the core instance LSP) the other RBridges that they have an attached IP multicast router
c) When an RBridge sees an IGMP report, it sends it to all the links (and only the links) that have IP multicast routers, and
also puts information about the requested groups in its (not sure if it should be per-VLAN instance or core instance) LSP
d) an IP multicast data packet for group G, tagged with VLAN A, will be sent to all the links in VLAN A that have an
IGMP-reported join from a listener, and also to links in VLAN A that have multicast routers.

Question 1) Should the group membership for VLAN A be reported in the core instance or the per-VLAN instance? The
reason for putting it in the core instance is so that core RBridges can filter sooner, for branches of the ingress-RBridge tree
that have no receivers downstream. The reason to put it in the per-VLAN instance is that this is potentially a large
and volatile information, especially if an obnoxious endnode decides to join and unjoin zillions of groups...why annoy
the core bridges in that case.

I'd argue for putting it in the per-VLAN instance, and I suspect most installations that are heavily depending on
high volume IP multicast applications won't be also using VLANs.

***********
Question 2: IGMPv2 suppresses a host report if an endnode E hears someone else has joined G.  RBridges are making
E think the whole campus is a single link, but RBridges are trying to optimize IP multicast and only send G to links
that requested G. I was worried about the case where an endnode E and an IP router R were sharing a link...if the IGMP
report was sent to R, then E would see the report and not join. But I was told that all IP multicast would be sent to all
links with IP multicast routers, so it's OK not to see E's join...the data would be sent on that link anyway. So what's
in the spec now works, but as I'll explain in question 3, if we try to optimize IP multicast delivery so that it isn't sent to
*all* IP multicast routers, then we don't want to suppress E's IGMP report.

We could solve the problem of suppressing E's IGMP report (if we do what I'll describe in question 3) in several ways:
a) assume that nobody is using IGMPv2 anymore and don't worry about that case
b) Have the Designated RBridge notice that the IGMP report it is about to
forward to the link is version 2, and in that case, rather than multicasting the report on
the link to the multicast MAC address derived from the IP multicast address (which is what version 2 does), unicasting
to the multicast router. I suspect this might confuse the IP multicast router, since it's receiving it unicast rather htan
what the spec says, but I also suspect that implementations might not check for this, so it might work.

My inclination is to not stand on our head for version 2, and furthermore not to bother with what I'll explain in question 3,
since I don't want supporting IP multicast to get so complicated that RBridges become prohibitive.

*********
Question 3: Should we optimize delivery of IP multicast data to only get sent to the "right" multicast router?

Not all IP multicast routers will be "interested" in data for G. I believe in "dense mode", they all will be. But in "sparse mode"
I believe only one IP multicast router needs tor receive G. Which IP multicast router should receive G is the following:
PIM has a Designated Multicast Router election (similar to IS-IS), electing DR. The default is that all groups go to DR.
However, sometimes it is discovered (through PIM sparse mode magic) that R2 should receive G, and not the DR. In
that case RBridges should deliver G to R2 and not to DR. This could be done by having R2 explicitly ask for G, just like
an endnode would.

Various potential solutions

a) RBridges send all IP mutlicasts to all IP multicast routers. Too bad if it's not completely optimized.
b) RBridges listen to the PIM election to decide which IP multicast router is the DR, 
and also listen to PIM asserts (or whatever it is that tells which IP multicast router other than DR should get G), to know
which groups to send to which IP multicast routers.
c) RBridges send G only to the DR. If an IP multicast router R2 that is not DR wants to receive G, it joins G, just like
an endnode would do, so that RBridges will deliver G to R2, in addition to sending it to DR.
d) as default, RBridges send all IP multicast traffic to all IP multicast routers, but define a message to be
sent between an IP multicast router R2 and its RBridge, that says "send me only these groups". Without receipt of
that message, the RBridges send all IP multicast traffic to R2.

I personally prefer a, since the others seem to be getting real comlicated.
b) seems way too PIM specific, and RBridges would have to change when PIM changed
c) won't work with IP multicast routers today that don't explicitly join the groups, since they wouldn't join G explicitly
d) at least has correct behavior without expecting the IP multicast routers to change. The extra message to be
defined is only an optimization beyond a).

So I prefer a) as simplest. My second choice is d).

Radia