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

From: Radia Perlman <[email-masked]>
Date: Thu, 04 Jun 2009 14:05:03 -0700

There's currently a flag in an LSP for an RBridge to say "don't send me 
layer 2 multicasts that aren't
derived from IP multicasts".

Would this ever be used? Can all layer 2 non-IP-derived multicasts 
really be lumped into the same
bucket and turned on and off as a unit?

It seems safer to me to remove that flag, since maybe there are some 
important layer 2
multicasts? Maybe it's intended as a safety thing, because 
IP-derived-multicasts have
to be explicitly requested (unless you are an IP multicast router), 
whereas the other
layer 2 multicasts would go everywhere?

And if we do have that flag, and someone says "I don't want 
non-IP-derived layer
2 multicasts", does that include ESADI information?

Radia

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2009 16:18:56 -0700

> bucket and turned on and off as a unit?

It might be useful not to make any assumptions about future use of L2
non-IP-derived mcast. Someone might come up with something that will
then break over rbridges, and that doesn't sound like a win...

Joe

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 6 Jun 2009 13:53:38 -0400

Hi Joe,

I'm assuming you think that we don't need this bit?

Thanks,
Donald

On Thu, Jun 4, 2009 at 7:18 PM, Joe Touch<[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Radia Perlman wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkooVl8ACgkQE5f5cImnZrt3OQCfeFr388KqsxmyZ7LJ/KRvvDJ2
> xHoAnRI5EW8dPYLtGEZzC1iQTVSYR6gq
> =Elnj
> -----END PGP SIGNATURE-----

---

From: Joe Touch <[email-masked]>
Date: Sat, 06 Jun 2009 11:22:23 -0700

> I'm assuming you think that we don't need this bit?

It seems like even having it around is asking for trouble, AFAICT.

Joe

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 10 Jun 2009 11:18:19 -0400

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

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.

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.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

On Sat, Jun 6, 2009 at 2:22 PM, Joe Touch<[email-masked]> wrote:
> iEYEARECAAYFAkoqs98ACgkQE5f5cImnZrtRlwCginXsRCpwmP1EIqr/xAGsjsPL
> Ku4AoJ2eROAbzwNoMM9Bhzc1V530svXo
> =HRnL

---

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 10 Jun 2009 09:38:53 -0700

I agree,

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

---

From: Joe Touch <[email-masked]>
Date: Wed, 10 Jun 2009 10:49:44 -0700

Donald Eastlake wrote:
> 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

> This was put

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 no "plenty of support" on the mailing list.
http://www.postel.org/pipermail/rbridge/2007-September/002470.html

> advertise they are connected to. It doesn't have any effect on layer 2

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.

> part of the design unless there is a clear consensus to re-open the

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

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 10 Jun 2009 10:52:24 -0700

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

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?

Joe

---

From: James Carlson <[email-masked]>
Date: Wed, 10 Jun 2009 15:40:23 -0400

> http://www.postel.org/pipermail/rbridge/2007-July/002400.html

Just to make clear (which itself might be impossible at this point):
the reason I supported it was for symmetry with the other multicast-
optimizing bits already defined.  If the implementation has some
reason to know that it has useful local information about non-IP
multicasts in use (e.g., the subnet in question runs only IP or
perhaps is known to use GMRP for all multicast addresses), then it can
set or reset the flag as needed.  If it doesn't (or can't) know about
non-IP multicast usage, then it should set it to 1 with the rest of
those who aren't snooping the multicast control protocols.

I somewhat doubt it's going to see much use, but it's also fairly
cheap -- as long as we already have to support IPv4 and IPv6 control
bits.  (And since, if you're lazy, you can just ignore it and let the
downstream discard the unwanted packets.)

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Joe Touch <[email-masked]>
Date: Wed, 10 Jun 2009 13:06:04 -0700

> downstream discard the unwanted packets.)

I'm seeing a "something operators can set as desired", but not a reason
they would ever want to set it. I particularly dislike the idea of
filtering multicasts based on upper layer info (i.e., whether it's IP or
not). IGMP is an optimization, but it seems like this bit could break
things when its use wasn't needed - and I still don't see a clear need.

Joe

---

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 10 Jun 2009 15:00:47 -0700

There is a L2 protocol called MMRP (used to be called GMRP) that allows 
me to do the equivalent of IGMP but for L2-only multicast (actually it 
can also be used for IP multicast). So, it should be possible for an 
Rbridge to say "don't send me any L2 multicast that isn't derived from 
IP multicast".

Dinesh
Joe Touch wrote:
> iEYEARECAAYFAkowEiwACgkQE5f5cImnZrvfzgCg6QgncAxHZVc5xThyFXFreWJS
> ndQAoIf7/c6vdfhkjCe93tilC8cMPJIe
> =0quk

---

From: Joe Touch <[email-masked]>
Date: Wed, 10 Jun 2009 15:06:46 -0700

> Rbridge to say "don't send me any L2 multicast that isn't derived from

I don't see why these two statements are related. If MMRP can also be
used for IP multicast or not, then how would an operator ever know when
to set this bit to "off"?

I'm suggesting that if we can't give clear advice to an operator on when
to set each value of a bit, we should not include it.

Joe

---

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 10 Jun 2009 22:04:23 -0700

Joe,

I see your point. I don't know the basis for this requirement. If an 
operator wanted to turn off all non-IP multicast, wouldn't turning on 
this bit be a good idea ? I guess your question is in what situations 
can an operator make this decision. Furthermore, I don't believe 
existing 802.1Q bridges provide such a funtionality. So, maybe getting 
rid of this bit is a good idea as you suggest.

Let me check with Dino and see if he remembers the need for this bit,

Dinesh
Joe Touch wrote:
> iEUEARECAAYFAkowLnYACgkQE5f5cImnZru4jACXRpWDmbsqx36tYQ71mAgNAPQF
> mQCfWccsjsmdv6jylLSIteO+s3M0Hto=
> =VPUF

---

From: Joe Touch <[email-masked]>
Date: Thu, 11 Jun 2009 07:37:51 -0700

Dinesh G Dutt wrote:
> can an operator make this decision. 

Exactly.

> Furthermore, I don't believe

Thanks. That'd be useful.

Joe

---

From: Dinesh G Dutt <[email-masked]>
Date: Thu, 11 Jun 2009 07:58:24 -0700

I checked and we don't need this bit. It was something that was put in 
for use in a network where MMRP was widely deployed, kind of thing. But 
as you pointed out, we can prune multicast effectively using the normal 
multicast pruning and don't need this bit.

Dinesh
Joe Touch wrote:
> iEYEARECAAYFAkoxFr8ACgkQE5f5cImnZrutDwCbBuwVDzPZgxdE/AB0ZcS+m0SQ
> ALgAn39Af0EuNqlfya38OGbfuJowMqGE
> =s9As

---

From: James Carlson <[email-masked]>
Date: Thu, 11 Jun 2009 11:02:18 -0400

> multicast pruning and don't need this bit.

... and I'm happy with or without the bit.  It's not important.

---

From: Joe Touch <[email-masked]>
Date: Thu, 11 Jun 2009 14:23:24 -0700

AOK - I'd like to make a motion to remove the bit.

I'd like to encourage a quick check that all other bits have clear
indications as to when an administrator would want to set/clear them,
based on either existing practice or specific guidance.

I.e., it should be more than just saying "here's what the bit does".

Thanks, all, for the exchange on this.

Joe

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 11 Jun 2009 23:50:54 -0400

Hi Joe,

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

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

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

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

> issue (my post) as there was to reach consensus to insert the bit in the

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.

> needed as a bit, and if so, what is the impact of changing it from the

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.

Thanks,
Donald

---

From: Joe Touch <[email-masked]>
Date: Thu, 11 Jun 2009 21:22:49 -0700

Donald Eastlake wrote:
...
> being used that has the bit set.

I have heard repeatedly what this does. The question we've had no
response to is:

	why would an operator want to do this?

In the absence of this bit, there would be no way to do something in
TRILL that isn't supported in existing L2 bridges (reportedly).

If the bit were set by an operator, there's the potential for silent
malfunction - where the operator thought there were no rbridges
downstream, but then that changed.

If this sort of thing isn't needed in existing L2s, why should it be
part of rbridges?

Joe

---

From: Radia Perlman <[email-masked]>
Date: Sun, 14 Jun 2009 13:10:17 -0700

Again, trying to close up these last little issues.

Having the bit certainly isn't expensive, but it would be really good to 
understand why it's there and
when it would be set, so we should probably wait for Dinesh to ask Dino.

I worry that if it's needed, it might need to be more granular that 
"all" or "no" layer 2 multicast. For instance,
there might wind up being something IGMP-like in layer 2 requesting 
specific multicast addresses or ranges.
(there might already be such a thing).

Radia

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 14 Jun 2009 16:03:28 -0400

> TRILL that isn't supported in existing L2 bridges (reportedly).

The L2 multicast registration protocols (GMRP/MMRP), as far as I can
see, allow you to register individual multicast addresses or to
register for all multicast traffic. All of the TRILL RBridge per VLAN
multicast bits (IPv4 and IPv6 derived and Other) do something that you
can't do with GMRP/MMRP in requesting huge blocks of multicast
addresses.

> downstream, but then that changed.

I don't think any of these three bits has any effect on multicast
frames flowing downstream in a distribution tree. If an RBridge is
doing multicast pruning, these bits just make that RBridge act so as
to assure that all multicast in the three categories gets any RBridges
it is directly or indirectly feeding...

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 14 Jun 2009 23:36:47 -0400

> when it would be set, so we should probably wait for Dinesh to ask Dino.

I believe he has and reports that Dino is not longer pushing for this bit.

> (there might already be such a thing).

As far as I can tell, there is no facility for giving ranges in the
layer-2 multicast registration protocols, only individual multicast
addresses or all multicast addresses.

Thanks,
Donald