[rbridge] When would an RBridge say "I don't want layer 2 multicast"?

[Donald Eastlake]

Hi Joe,

Sorry for the delay in reply. See below...

On Wed, Jun 10, 2009 at 1:52 PM, Joe Touch<touch at isi.edu> wrote:
> Donald Eastlake wrote:
>> The Other Multicast bit was added after Dino Farinacci advocated it at
>> the last Chicago meeting. (See minutes:
>> http://www.ietf.org/proceedings/07jul/minutes/trill.txt)
>
> The minutes indicate a suggestion to put the bit in, but not a clear
> reason why it's needed. The notes only indicate that this was a
> "suggestion", then declare "consensus to be confirmed on the list.
>
> The post you made on the email list in July indicates consensus at the
> meeting, even though that wasn't indicated in the minutes:
> http://www.postel.org/pipermail/rbridge/2007-July/002399.html

The minutes are not a transcript or blow by blow description. As I
recall, Dino Farinacci was at the meeting. There was discussion of the
previously single multicast router attachment bit and how it should be
split into separate IPv4 and IPv6 multicast router attachment bits,
which attract all IPv4 derived and IPv6 derived multicast frames,
respectively. Dino spoke of how you should do whatever you can to
control the flooding of multicast traffic and asked if a similar bit
could be added for the non-IP derived frames.

As the minutes say: "This met with general agreement." As I recall,
there appeared to be virtually unanimous agreement among those in the
room. In fact agreement so strong that someone, Radia if I remember
correctly, asked Dino if we thought we should add a fourth
configuration bit that would indicate whether the RBridge wanted
Broadcast frames. Dino replied that he thought that would be a bad
idea as, by definition, Broadcast frames are supposed to go to all
stations. (All of this is actually per VLAN.)

>> This was put
>> through a consensus call on the working group mailing list resulting
>> in the formal consensus determination here:
>> http://www.postel.org/pipermail/rbridge/2007-September/002470.html.
>
> Besides your mail, there was only one post from James Carlson endorsing
> the idea:
> http://www.postel.org/pipermail/rbridge/2007-July/002400.html
>
> Two months later you declare consensus based on "plenty of support and
> almost no opposition". There was no discussion on the mailing list.
> There was not really "plenty of support" on the mailing list.
> http://www.postel.org/pipermail/rbridge/2007-September/002470.html

Consensus determination is not based solely on the working group
mailing list. And, of course, it can not be based solely on opinions
at a face-to-face working group meeting. But chairs are entitled to
take both into account. Even the strongest support at a meeting must
be tested on the mailing list. In this case, what appeared to be quite
strong support at the meeting was confirmed on the mailing list by the
lack of any opposition on the mailing list and it is just icing on the
cake that there was additional support on the mailing list.

I stand by the consensus determination that Erik and I made and that,
overall, there was plenty of support in the working group..

>> This bit has been in the draft since verison -06. It defaults to "on"
>> so, unless you go to some effort to configure it to off, all RBridges
>> do get all the non-IP derived multicast traffic for the VLANs they
>> advertise they are connected to. It doesn't have any effect on layer 2
>> or TRILL control frames.
>
> The question is "why do we need this complexity"? I appreciate it won't
> cause problems if defaulted 'on', but having a bit means making sure
> it's implemented and tested for vendors.

It provides another tool for controlling the burden of multicast
traffic with a per VLAN granularity. Having it in the protocol imposes
some costs. Different people may differ in judgement as to the balance
of these factors and whether the bit should be in the protocol.

>> In light of all this, I am very reluctant to consider changing this
>> part of the design unless there is a clear consensus to re-open the
>> issue.
>
> Well, there's just as much consensus on the mailing list to open the
> issue (my post) as there was to reach consensus to insert the bit in the
> first place ;-)

The consensus to add this bit was based on overwhelming support at a
meeting as confirmed by no opposition and a further support on the
mailing list.

> Maybe what I'm asking is at least to clarify the issue. Is it really
> needed as a bit, and if so, what is the impact of changing it from the
> default value?

No, it's not "needed" in a strict sense. Neither is unicast. You could
just handle everything as if it were  broadcast. Like almost
everything, the bit has pluses and minuses.

When you ask the impact of changing it from its default value of "on"
to "off", for one more VLANs, are you saying that the protocol
specification is ambiguous?

The optional multicast optimization in TRILL applies only to IP
derived multicast. The IPv4 and IPv6 multicast router attachment bits
attract (per VLAN) all IPv4 and IPv6 derived multicast traffic. The
Other Multicast bit attracts all other multicast traffic and defaults
to on.

In the absence of this bit, there would be no way, within the TRILL
protocol, to control non-IP derived multicast and all of it would have
to be sent to all RBridges in the same VLAN as the traffic. With the
bit, it is possible to clear the bit and stop non-IP derived multicast
from being decapsulated at the RBridge or even getting to the RBridge
if there are no other RBridges downstream in the distribution tree
being used that has the bit set.

> Joe

Thanks,
Donald