Subject: [rbridge] Summary of layer 2 multicast stuff

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 8 May 2006 16:04:34 -0400

Radia,

	Please see below...

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
--> Sent: Monday, May 08, 2006 12:38 PM
--> To: rbridge at postel.org
--> Subject: Re: [rbridge] Summary of layer 2 multicast stuff
--> 
--> 
--> 
--> Russ White wrote
--> 
--> >
--> > I would leave the specific mechanism open, while requiring 
--> > optimization, and write a separate doc on how to actually do 
--> > the optimization using IGMP snooping. Other mechanisms might 
--> > show up that might be more efficient/etc., so there's no 
--> > reason to tie the rbridges docs to one specific mechanism.
--> >
--> I can't imagine new mechanisms happening, and I don't see how it 
--> simplified anything to make it a separate document. 

You're joking, right?

This is all about new mechanisms to do Ethernet forwarding
and we're talking about using specific mechanisms to allow
us to optimize multicast/VLAN forwarding.

Given this context, how can we not imagine new mechanisms?

At first, it seems simpler to keep this in a single document,
and that may well be the way to go.  However, if we imagine
that other mechanisms might also be used, then we should be
writing the main protocol document such that these other ways
can be "plugged in".

--> And although it is "safe" for some inner RBridge not to filter, 
--> it isn't safe to make it optional for RBridges to discover 
--> locations of multicast receivers and announce the location of 
--> them...because filtering RBridges will be assuming that lack of 
--> information about interest on a link means they don't need to 
--> forward there. So that form of optimization is not safe to be 
--> optional.

I don't think anyone is arguing that the discovery of multicast
listener locations should be optional.  What I see being argued
here is that we should not restrict the mechanism to apply only
to what we know now, specifically that we could use IGMP snooping
to learn MAC multicast associated IP multicast listeners, unless 
we do not have a choice.

I have also seen suggestions made that make it seem as if we 
certainly have a choice.

--> 
--> >
--> > Or, make IPv6 optimization optional, and leave it outside 
--> > the scope of this doc to discuss possible mechanisms. If 
--> > we separate this problem out, we can think about it later, 
--> > once the base documents are done, and we might possibly 
--> > come up with a solution.
--> >
--> As above, if we make discovery of IPv6 receivers and announcement
--> of them optional now, I don't think it will ever be safe to add 
--> it later, since there will be some RBridges that would not recognize
--> whatever the announcement is, and would not advertise it, so future 
--> RBridges would not be able to assume it is safe to deliver to a link 
--> that they don't know for certain does NOT have listeners.
-->

If this were true, we would not now be able to use BGP for stuff
like IPv6 and MPLS-VPNs.

In most of the protocol work I've seen done in the IETF in recent
years, the possibility that the protocol may need to be extended -
and that version compatibility (possibly including some form of 
capability negotiation) MAY need to take place - is something that 
MUST be built into the first version of the protocol.

I think it is a bad idea to assume that will not be the case with
RBridge protocols as well.

In the case of this particular discussion about multicast listener
announcements, for example, we SHOULD define a protocol mechanism 
for carrying these announcements that -

1) generally defines how we would transport these announcements
   across the RBridge campus (including all information that we
   know we will need in order to use these annoucements)
2) specifically defines the details of the mechanism as we would
   define it for what we know now (including IP multicast associated
   MAC mulitcast addresses learned from IGMP)
3) defines behaviors for all RBridges with respect to handling of
   any such announcements that are not understood by a local RBridge
   (e.g. - the local RBridge transports them transparently, with the
   content treated as opaque, to adjacent peers along with any other
   announcements)

Also defined should be the mechanism used to determine forwarding
tactics for MAC multicast traffic when there is a mix of traffic
where some MUST be treated as if it were broadcast and others MAY
be filtered based on "interest" information learned from other
RBridges.

--> I suspect that sentence has too many negatives to parse, 
--> but I hope I got the parity right.
--> 
--> Radia
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->

---

From: riw at cisco.com (Russ White)
Date: Mon, 08 May 2006 17:55:26 -0400

> writing the main protocol document such that these other ways

In fact, I can already imagine one, which is why I said this.... It's
not a matter of any new idea being brilliant, just that we should leave
room for it, probably. :-)

> to learn MAC multicast associated IP multicast listeners, unless 

Agreed.

:-)

Russ

- --
riw at cisco.com CCIE <>< Grace Alone