Subject: [rbridge] Should layer 2 or layer 3 IP Multicast addresses be advertised?

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Tue, 2 May 2006 18:01:37 -0400

Radia,

	I would lean toward (b).

	In part, that is because we don't (to my knowledge) have
a working group consensus to necessarily include "IP multicast"
(as opposed to MAC multicast) awareness in RBridges.  I think 
we need to have that consensus before we talk about including 
any kind of IPv4/v6 addresses in RBridge advertisements. 

	We may need to have consensus on other things before we 
do that as well - like how appropriate it is to use RBridge
protocols as a substitute for multicast routing protocols. 

	But my leaning is also because we can be more consistent 
in storing MAC layer reachability if we are being consistent 
and only advertising MAC layer reachability in RBridge protocol.

	In general, multicast MAC address advertisements will be
relatively sparse in comparison with unicast MAC addresses, so
using compression that only works for multicast addresses seems
to lean in the direction of optimizing for the uncommon case.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
--> Sent: Tuesday, May 02, 2006 5:31 PM
--> To: rbridge at postel.org
--> Subject: [rbridge] Should layer 2 or layer 3 IP Multicast 
--> addresses be advertised?
--> 
--> I'm trying to write up the RBridge/IP multicast 
--> interaction. What should 
--> a Designated RBridge put into
--> its link state information regarding IP multicast listeners?
--> 
--> The possibilities are:
--> a) IPv4 multicast addresses, and IPv6 multicast addresses
--> b) layer 2 multicast addresses derived from any of the groups the 
--> RBridge has heard in
--> IGMP Notification Messages from attached endnodes.
--> c) compressed layer 2 multicast addresses (i.e., leave off 
--> the top two 
--> bytes).
--> 
--> Either works. Does anyone care? The nice thing about b) is that it 
--> doesn't have to be different information
--> for IPv4 than IPv6. The nice thing about a) is that it is a 
--> little bit 
--> less information in the case of IPv4 (but
--> more information in the case of IPv6). The nice thing about 
--> c) is that 
--> it compresses the information
--> (does IPv6 have the same block of layer 2 multicast 
--> addresses derived 
--> from IPv6 multicast addresses
--> as for IPv4 multicast addresses?)
--> 
--> If the IPv6 and IPv4 layer 2 blocks for derived multicast 
--> addresses, I'd 
--> lean towards c). But does
--> anyone else have an opinion?
--> 
--> Radia
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->

---

From: lucyyong at huawei.com (Lucy Yong)
Date: Tue, 02 May 2006 17:23:46 -0500

I agree with Eric that multicast MAC address is relatively spares,
therefore, no need to compress. My question is how to generate a unique
multicast MAC address? Who has the authority to generate that and base on
what rules?

Lucy
-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Gray, Eric
Sent: Tuesday, May 02, 2006 5:02 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Should layer 2 or layer 3 IP Multicast addresses
beadvertised?

Radia,

	I would lean toward (b).

--
Eric

_______________________________________________
rbridge mailing list
rbridge at postel.org
http://www.postel.org/mailman/listinfo/rbridge

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 02 May 2006 15:39:59 -0700

The current draft says IS-IS routing messages (for RBridges) will be 
sent to a different multicast
address than the IP router instance of IS-IS. That seems reasonable.

Another question though is what should the Ethertype be for such messages?

a) the same as IS-IS for routers?
b) a new Ethertype?
c) the same as the new Ethertype we will need assigned to indicate that 
the frame is
an RBridge-encapsulated frame?

Not even sure what the pros and cons are. Perhaps a) might freak out an 
IS-IS router...to see something
with the IS-IS Ethertype but to an unknown multicast address? If we do 
c), then we need a way of
distinguishing this as an IS-IS packet rather than an encapsulated data 
packet. If we do b), then we
eat up Ethertypes. How precious are they?

Radia

---

From: dino at cisco.com (Dino Farinacci)
Date: Tue, 2 May 2006 19:10:51 -0700

>> a) the same as IS-IS for routers?

    Nope. Keep them separate so they don't collide.

>> b) a new Ethertype?

    IS-IS doesn't run in an ethertype now. It runs in a 802.2 DSAP. I think 
    this shouldn't change. Just in case there is hardware out there that might
    key on this field. DSAP space is 8-bits, so they have historically been
    treated as precious.

>> an RBridge-encapsulated frame?

    I can't parse this. What do you mean? The same as what?

    I would vote for:

    d) A new MAC address coming out of the 0x0180C2 OUI range.

Dino