[rbridge] FYI: Where IGMP snooping and multicast router discovery are written up
tme at multicasttech.com (Marshall Eubanks) Fri, 07 April 2006 04:09 UTC
From: "tme at multicasttech.com"
Date: Fri, 07 Apr 2006 00:09:32 -0400
Subject: [rbridge] FYI: Where IGMP snooping and multicast router discovery are written up
In-Reply-To: <4435DA88.70005@sun.com>
References: <44316F4F.8060202@sun.com> <4435DA88.70005@sun.com>
Message-ID: <8460AD46-CD09-4A2F-BBB1-AAEACF85E0C2@multicasttech.com>
Dear Radia; On Apr 6, 2006, at 11:20 PM, Radia Perlman wrote: > There's two documents that Bill Fenner pointed me to, and I will put > pointers into > the protocol draft (rather than duplicating all the mechanisms). > > One document explains how to find multicast routers. This is important > because > multicast packets and IGMP reports > must be sent to each every link on which there is a multicast router. > > The multicast router discovery is explained in: > > http://tools.ietf.org/html/rfc4286 > Since this is an RFC, so we don't have to duplicate what's in it, > and we can just > point to it. > > The other document explains how to recognize IGMP packets of > various sorts. > > http://tools.ietf.org/wg/magma/draft-ietf-magma-snoop/draft-ietf- > magma-snoop-12.txt > > It is unfortunately an internet draft, but hopefully it will become > an RFC. Does anyone know whether it will? If it will, then we can > point to it, rather The draft draft-ietf-magma-snoop-12.txt is in the RFC editor queue, and has been for a while (2003-11-24). This was being held up because of a reference to draft-ietf-magma- mrdisc AKA RFC 4286, but this has now of course cleared up and I believe that now it's just in the RFC ED backlog. The co-chairs of MAGMA (cc'ed here) should know more, but I would guess it will be a numbered RFC very soon now. Regards Marshall > than duplicating the content. I'll have to read it carefully, but > it's possible RBridges > will want to distribute the IGMP messages slightly differently than > bridges would, > for instance, by announcing receivers in link state information > rather than > learning it from forwarding IGMP announcements. IGMP announcements > still need to > be forwarded, but only to links with multicast routers. The magma > draft says > to only filter at the last hop, but since RBridges will be > informing each other of > the location of multicast routers, IGMP reports can be suppressed > upstream, though > this isn't a large optimization. > > Anyway, since RBridges can work a little differently from bridges, > we can't just point > to this document. On the other hand, it's real nice not to have to > explain the > format of IGMP messages of various versions. If n documents in k > different working > groups all try to do that, then if a new version of IGMP occurs, it > will be very > difficult to find all affected documents. > > I'll read this document carefully and as much as possible point to > it rather than > duplicating its content, but others may also want to read it and > think about what > differences we might want in the RBridge world. > > Unless of course this isn't intended to ever be an RFC, in which > case we'll have > to capture all the relevant content...I assume someone will let us > know the intention > of the magma draft. > > Radia > > > > > > > > > > _______________________________________________ > rbridge mailing list > rbridge at postel.org > http://www.postel.org/mailman/listinfo/rbridge
- [rbridge] Ready to accept as WG documents? Erik Nordmark
- [rbridge] FYI: Where IGMP snooping and multicast … Radia Perlman
- [rbridge] FYI: Where IGMP snooping and multicast … Marshall Eubanks
- [rbridge] FW: Ready to accept as WG documents? Eastlake III Donald-LDE008
- [rbridge] FW: Ready to accept as WG documents? Russ White
- [rbridge] FW: Ready to accept as WG documents? Gray, Eric