[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