Subject: [magma] I-D ACTION:draft-ietf-magma-igmp-proxy-06.txt

From: [email-masked]
Date: Wed, 07 Apr 2004 11:35:43 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multicast & Anycast Group Membership Working Group of the IETF.

	Title		: IGMP/MLD-based Multicast Forwarding ('IGMP/MLD Proxying')
	Author(s)	: B. Fenner, et al
	Filename	: draft-ietf-magma-igmp-proxy-06.txt
	Pages		: 11
	Date		: 2004-4-6
	
In certain topologies, it is not necessary to run a multicast routing
   protocol. It is sufficient for a device to learn and proxy group
   membership information and simply forward multicast packets based
   upon that information.  This draft describes a mechanism for
   forwarding based solely upon Internet Group Management Protocol
   (IGMP) or Multicast Listener Discovery (MLD) membership information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-magma-igmp-proxy-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-magma-igmp-proxy-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-magma-igmp-proxy-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 7 Apr 2004 22:05:26 +0300 (EEST)

> http://www.ietf.org/internet-drafts/draft-ietf-magma-igmp-proxy-06.txt

Does this take all IESG feedback in the account?  At least I've given 
some comments through ops-dir, which are recorded in the I-D tracker.

Some additional editorial comments below:

1. Introduction

   This document applies spanning tree multicast routing [MCAST] to an
   Internet Group Management Protocol (IGMP) or Multicast Listener
   Discovery (MLD) only environment.  The topology is limited to a tree,
   since we specify no protocol to build a spanning tree over a more
   complex topology.  The root of the tree is assumed to be connected to
   a wider multicast infrastructure.

==> the first line seems out of place: this document has little to do
with spanning tree multicast routing, as there is not spanning tree
protocol being run.  Maybe reword to like:

   This document defines a mechanism for proxying
   Internet Group Management Protocol (IGMP) or Multicast Listener
   Discovery (MLD) messages instead of using a multicast routing protocol.
   The topology is limited to a tree,
   since we specify no protocol to build a spanning tree over a more
   complex topology.  The root of the tree is assumed to be connected to
   a wider multicast infrastructure.

....

1.3 ...

   This document is a product of the Multicast & Anycast Group
   Membership (MAGMA) working group within the Internet Engineering Task
   Force. Comments are solicited and should be addressed to the working
   group's mailing list at [email-masked] and/or the authors.

==> this could probably be removed.  Typically these notes are in the 
boilerplate, which is removed upon RFC publication.  But as this 
isn't, it'd stay in the RFC.  So, it should probably be removed or 
somehow marked for removal.

   (multicast address, group timer, filter-mode, source-element list)
   tuple) on an interface.

==> s/tuple)/-tuple/

   The proxy device sends IGMP/MLD membership reports on the upstream
   nterface when queried, and sends unsolicited reports or leaves when

==> s/nterface/interface/

  IGMPv3/MLDv2 specification[RFC 3376,MLDv2] to create the membership

==> s/specification/specification /

  IGMP/MLD-based forwarding does not provide "upstream loop" detection
   mechanism as described in section 3. Hence to avoid the problems
   caused by an "upstream loop", it MUST be administratively assured
   that such loops don't exist when deploying IGMP/MLD Proxying.

==> this is an operational requirement, not something that an
implementation can check, so s/MUST/must/ ?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Pekka Savola <[email-masked]>
Date: Wed, 7 Apr 2004 22:05:26 +0300 (EEST)

1. Introduction

....

1.3 ...

==> s/tuple)/-tuple/

---

From: Brian Haberman <[email-masked]>
Date: Thu, 08 Apr 2004 13:42:40 -0400

Hi Pekka,
      I don't see these comments in the tracker, not sure why.  Anyways,
they all seem editorial in nature and can be dealt with either at the
RFC editor or in auth48.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 08 Apr 2004 13:42:40 -0400

Hi Pekka,

Regards,
Brian