[rbridge] FYI: Where IGMP snooping and multicast router discovery are written up

[Marshall Eubanks]

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