[rbridge] Need help sorting out IP multicast with RBridges

[Eastlake III Donald-LDE008]

Hi,

Since no one else has responded to this message, see some comments from
me as a TRILL WG member below at @@@

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia.Perlman at sun.com
Sent: Friday, July 14, 2006 10:58 AM
To: rbridge at postel.org
Subject: [rbridge] Need help sorting out IP multicast with RBridges

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?

@@@ I'm sure others know more, but it seems to me that you want to look
for both PIM messages, to work now, and Multicast Router Discovery
messages in the hope that they will be implemented and you will thus
work for various IP multicast protocols in the future.

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.

@@@ I agree.

***********
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 than 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.

@@@ The answer here depends somewhat on knowing just how common the
implementation is of which versions which I'm sure others can answer
better than me. What is the level of use of IGMPv2? It would be nice to
be able to ignore older versions if their use is insignificant or
rapidly declining towards insignificance.

*********
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 to 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.

@@@ Based on the arguments thus far, I think "a" should be the mandatory
to implement level of optimization.

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).

@@@ It seems reasonable to specify this sort of thing as an optional
additional level of optimization. Defining a message from a multicast
router to its Rbridge saying what groups it wants seems good for the
future. However, so the optimization would work for current multicast
routers, is it all that hard to just monitor the PIM election? Assuming
that sending multicast to the PIM DR would cause it to be forwarded to
the "right" multicast router(s) if that isn't the DR, them I'm not sure
monitoring PIM assertion of such other routers would be worth it.

@@@ Monitoring PIM and also incorporating a better future solution for
this optimization seems somewhat parallel to PIM & MRD for finding
multicast routers in the first place.

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

Radia

@@@ Anyway, the above is my current opinion as a WG member.

@@@ Thanks,
@@@ Donald