> On Mon, 09 Feb 2004 12:14:35 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
>> Having said that,
>> if you worry about the document boundary, you can simply say "delay
>> joining to the multicast group by a random delay. Once you have joined,
>> send the ND packet."
> Hmm, I tend to
> On Sun, 08 Feb 2004 19:38:08 +0200,
> Jari Arkko <[EMAIL PROTECTED]> said:
>> Regarding option 3:
>> pro: this is a complete solution of the problem, which works with
>> MLD snooping switches
>> con: this can be regarded as spec-violation, and we may have to
>> worry about conflict with
> On Sun, 08 Feb 2004 14:33:01 -0500,
> Brian Haberman <[EMAIL PROTECTED]> said:
> I don't like the idea of a random delay in the MLD Reports. As I
> said in another note, it either adversely affects the logic in the
> MLD specs or causes application delays for non-LL groups.
> Is havin
Hi Brian,
Brian Haberman wrote:
I don't like the idea of a random delay in the MLD Reports. As I
said in another note, it either adversely affects the logic in the
MLD specs or causes application delays for non-LL groups.
Is having a delay in the NS transmission alone sufficient? So that
the Rep
> On Sun, 8 Feb 2004 09:15:11 -0800 (PST),
> Fred Templin <[EMAIL PROTECTED]> said:
> Do you have a timeframe for when you will be posting RFC2462(bis)
> to the I-D repository?
I'll post it as a wg document (draft-ietf-ipv6-rfc2462bis-00.txt) by
the cutoff date for initial submissions (F
Markku,
Markku Savela wrote:
From: Brian Haberman <[EMAIL PROTECTED]>
- desire to avoid packet storms upon booting many nodes simultaneously
2710 accomplishes this by using message suppression. If a node hears a
Report for the same group, it cancels the transmission of any pending
Reports it h
Alain Durand <[EMAIL PROTECTED]> wrote:
|I think people are confusing the notion of 'permanent' and 'stable'
|addresses.
On the contrary, I think that it has not yet been demonstrated that they
are different for practical purposes. An address that has been around for
100 years but which disappe
Hi Juergen,
Thanks for the feedback. My comments inline.
Juergen Schoenwaelder wrote:
Rajiv Raghunarayan writes:
Rajiv> The IESG review suggested that we provide a discontinuity timer
Rajiv> for the counters in the mib - could be via sysUpTime or a new
Rajiv> discontinuity object. But we state
> From: Brian Haberman <[EMAIL PROTECTED]>
> > - desire to avoid packet storms upon booting many nodes simultaneously
>
> 2710 accomplishes this by using message suppression. If a node hears a
> Report for the same group, it cancels the transmission of any pending
> Reports it has for the group
I don't like the idea of a random delay in the MLD Reports. As I
said in another note, it either adversely affects the logic in the
MLD specs or causes application delays for non-LL groups.
Is having a delay in the NS transmission alone sufficient? So that
the Report is sent immediately and the N
Jari Arkko wrote:
Brian Haberman wrote:
Group management protocols can be considered a low-level member
of the routing protocols. That means, random delays in sending
state changes affect the routing/forwarding infrastructure of the
network. Introducing delays in the sending of those state ch
Brian Haberman wrote:
Group management protocols can be considered a low-level member
of the routing protocols. That means, random delays in sending
state changes affect the routing/forwarding infrastructure of the
network. Introducing delays in the sending of those state changes
doesn't seem to
Jinmei,
Do you have a timeframe for when you will be posting RFC2462(bis)
to the I-D repository?
Thanks - Fred
[EMAIL PROTECTED]JINMEI Tatuya / [EMAIL PROTECTED]@C#:H(B <[EMAIL PROTECTED]> wrote:
> On Sun, 08 Feb 2004 09:02:54 -0500, > Brian Haberman <[EMAIL PROTECTED]>said:> Given my
> On Sun, 08 Feb 2004 09:02:54 -0500,
> Brian Haberman <[EMAIL PROTECTED]> said:
> Given my point above, I would argue that we shouldn't add a delay to
> MLD messages.
So, do you have any opinion among the options I raised in this thread?
1. no change in rfc2462bis (expecting MLDv1 and/
> On Thu, 5 Feb 2004 17:32:03 -0800 (PST),
> Erik Nordmark <[EMAIL PROTECTED]> said:
> So do we or do we not want to
> 1. specify the per-interface router definition
> 2. specify how RFC 2461 (and 62) behave on a multihomed node
Hmm, I see the discussion about the definition of per-inter
Greg Daley wrote:
Hi Jinmei,
JINMEI Tatuya / wrote:
On Thu, 5 Feb 2004 17:55:08 +0200, Markku Savela
<[EMAIL PROTECTED]> said:
It should be noted that the Neighbor Solicitation is usually not the
first message. As stated above, the sending node must join the
solicited-node multicast a
> On Fri, 06 Feb 2004 13:50:44 +0200,
> Jari Arkko <[EMAIL PROTECTED]> said:
> JINMEI Tatuya wrote:
>> The autoconfiguration process specified in this document applies only
>> to hosts and not routers. Since host autoconfiguration uses
>> information advertised by routers, routers will n
> On Sat, 07 Feb 2004 22:44:19 +1100,
> Gregory Daley <[EMAIL PROTECTED]> said:
>> My conclusion is that the right thing is to update RFC 2710
>> and require a delay. This removes collisions from both MLD
>> and DAD.
> I think that the problem there may be that RFC-2710 is
> being repla
> On Fri, 06 Feb 2004 13:59:36 +1100,
> Greg Daley <[EMAIL PROTECTED]> said:
> The only existing reasons to do MLD on these addresses are
> so that MLD proxies, and snooping switchescan request
> multicast transport for those addresses. Unless this
> is performed correctly, the node perf
> On Fri, 06 Feb 2004 13:34:23 +0200,
> Jari Arkko <[EMAIL PROTECTED]> said:
>> To address rfc2462bis issue 271, "An implementation may want to use
>> stable storage for autoconfigured addresses", I've added the following
>> new (sub)section:
>>
>> ===
20 matches
Mail list logo
