[magma] IESG on draft-ietf-magma-mld-source-03.txt
Erik Nordmark <Erik.Nordmark@sun.com> Wed, 06 November 2002 15:05 UTC
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24697; Wed, 6 Nov 2002 10:05:53 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6F8Iv19419; Wed, 6 Nov 2002 10:08:18 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6F7cv19312 for <magma@optimus.ietf.org>; Wed, 6 Nov 2002 10:07:38 -0500
Received: from patan.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24617 for <magma@ietf.org>; Wed, 6 Nov 2002 10:05:06 -0500 (EST)
Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02194 for <magma@ietf.org>; Wed, 6 Nov 2002 08:07:34 -0700 (MST)
Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL, v2.2) with SMTP id gA6F7ML04973 for <magma@ietf.org>; Wed, 6 Nov 2002 16:07:22 +0100 (MET)
Date: Wed, 06 Nov 2002 16:04:17 +0100
From: Erik Nordmark <Erik.Nordmark@sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@sun.com>
To: magma@ietf.org
Message-ID: <Roam.SIMC.2.0.6.1036595057.30444.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET="US-ASCII"
Subject: [magma] IESG on draft-ietf-magma-mld-source-03.txt
Sender: magma-admin@ietf.org
Errors-To: magma-admin@ietf.org
X-BeenThere: magma@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=unsubscribe>
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Post: <mailto:magma@ietf.org>
List-Help: <mailto:magma-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=subscribe>
The IESG discussed mld-source last week. Here are the comments. Thomas: > MLD Report and Done messages MUST be sent with a valid link-local > address as the IPv6 source address. If a valid link-local address is > not available, the message MUST be sent with the unspecified address > (::) as the IPv6 source address. A bit of a nit, but the MUSTs are almost contradictory. It's a bit odd to say: Do X. Well except if you can't, in which case you do Y. Better to rewrite something like: MLD Report and Done messages are sent with a link-local address as the IPv6 source address, if the one has been assigned to the interface. If a none exists (e.g., one hasn't been assigned to the interface yet), the message is sent with the unspecified address (::) as the IPv6 source address. nit: RFC 2119 reference should be normative rather than informative. Finally, the document really could include a bit more context about why the document exists and what problem is being solved. Based on some discussions with the author, the exact problem being solved seems to be: The rules and desired behavior with regards to receiving multicast traffic prior to having an IP address need clarification. Before assigning an LL address to an interface, a node needs to run DAD. But DAD involves recieving multicast traffic sent to the solicited node multicast address. But joining a multicast group involves running MLD. The MLD spec says that MLD messages MUST be sourced from a LL source address. This is needed even for LL multicast addresses due to l2 bridge snooping. Thus, clarifications/guidelines regarding the handling of joining multicast groups when one has no LL address are needed. It would be good to get words into the document that explain this better. Also, I think it would be good to add some explicit wording to the document making it clear which rules in 2710 are being changed. I particular, it would be good to indicate that receivers should not drop packets with a source address of unspecified. In general, you might want to say something about what problems have been encountered in practice from the current wording, and whether this change will result in different/better/worse behavior. For example, should an implementation (once it has a valid ll address) also run MLD again with its new address, to be sure that it interoperates well with routers that drop packets with a source address of unspecified? --- _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma
- [magma] IESG on draft-ietf-magma-mld-source-03.txt Erik Nordmark