[magma] RC3810: MLD Hop Limit is 1 / random reply time / exclude

Jeroen Massar <jeroen@unfix.org> Mon, 27 September 2004 12:49 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26346; Mon, 27 Sep 2004 08:49:52 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBv4b-0005Es-QO; Mon, 27 Sep 2004 08:57:47 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CButf-0002E9-Kg; Mon, 27 Sep 2004 08:46:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBulN-0001Ii-4r for magma@megatron.ietf.org; Mon, 27 Sep 2004 08:37:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25801 for <magma@ietf.org>; Mon, 27 Sep 2004 08:37:51 -0400 (EDT)
Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBusz-00053S-A7 for magma@ietf.org; Mon, 27 Sep 2004 08:45:45 -0400
Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 71F657FB7 for <magma@ietf.org>; Mon, 27 Sep 2004 14:37:49 +0200 (CEST)
Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 11698-43 for <magma@ietf.org>; Mon, 27 Sep 2004 14:37:44 +0200 (CEST)
Received: from [9.4.68.125] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 996678682 for <magma@ietf.org>; Mon, 27 Sep 2004 14:10:05 +0200 (CEST)
From: Jeroen Massar <jeroen@unfix.org>
To: magma@ietf.org
Organization: Unfix
Message-Id: <1096286992.5629.23.camel@firenze.zurich.ibm.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2)
Date: Mon, 27 Sep 2004 14:09:52 +0200
X-Virus-Scanned: purgatory.unfix.org - http://unfix.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Subject: [magma] RC3810: MLD Hop Limit is 1 / random reply time / exclude
X-BeenThere: magma@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=unsubscribe>
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>
Content-Type: multipart/mixed; boundary="===============1337872260=="
Sender: magma-bounces@ietf.org
Errors-To: magma-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87

[On request, seperatly to magma, next to ipv6]

Hi,

I was reading through the, IMHO overly complex, RFC3810 for MLDv2 making
sure that ecmh will implement it correctly and found a couple of odd
things.

First of all for MLD we set the Hop Limit to 1, while for ND we use 255
so that we are sure that the ND's are on link. Why is this not done for
MLD's too ?

Also 6.2
8<--------
   Instead of responding immediately, the node
   delays its response by a random amount of time, bounded by the
   Maximum Response Delay value derived from the Maximum Response Code
   in the received Query message. 
-------->8
but also:
8<--------
   If it does, a delay for a response is randomly selected in the range (0,
   [Maximum Response Delay]), where Maximum Response Delay is derived
   from the Maximum Response Code inserted in the received Query
   message. 
-------->8
6.3 then further notes (repeating again, but a bit more text):
8<--------
      This naive algorithm may result in bursts of packets when a node
      listens to a large number of multicast addresses.  Instead of
      using a single Interface Timer, implementations are recommended to
      spread transmission of such Report messages over the interval (0,
      [Maximum Response Delay]).  Note that any such implementation MUST
      avoid the "ack-implosion" problem, i.e., MUST NOT send a Report
      immediately upon reception of a General Query.
-------->8

Shouldn't the response thus be generated after random(3+,MRC) ?

Another item I couldn't clearly identify from the text, at least it
puzzled me, was the following situation:

Host A wants to receive ff3e:30:2001:db8:300:0:8008:ad10 IN(::)
Host B wants to receive ff3e:30:2001:db8:300:0:8008:ad10 EX(2001:db8::1)

What does the router have to send forward in this case? I assume it
would be to transit it anyway, because at least one node wants it, B can
filter out these packets and not deliver them. Is this assumption
correct?

Btw, anyone counted the number of times 'nevertheless' is in the text ?
:)

Greets,
 Jeroen

_______________________________________________
magma mailing list
magma@ietf.org
https://www1.ietf.org/mailman/listinfo/magma