On Tue, Oct 29, 2002 at 07:08:55PM +0100, Hesham Soliman (EAB) wrote:
>
> Optimistic DAD needs to be analysed carefully to make sure
> that the failure cases are rare and do not justify killing
> optimistic DAD. I think this analysus is ongoing.
Yep. it's ongoing! No-one seems to have come up w
t;[EMAIL PROTECTED]>;
"Thomas Narten" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, October 30, 2002 3:59 AM
Subject: RE: Changing RS Reply Timing for Mobile IPv6
>
> > I think what I've been hearing from Jim Bound and others
> > that they
> I think what I've been hearing from Jim Bound and others
> that they would rather
> not have these specialized features that FMIPv6 is
> specifying as general purpose
> for any IPv6 router, because they want to move forward with
> their IPv6
> (including base MIPv6 which works w
> > Do you anticipate that the changes in FMIPv6 for access
> > routers will be in all
> > IPv6 routers?
>
> => I don't know. But I know that any router can be
> an "access router". People don't develop a special router
> because it will be connected to an ethernet that has a an
> 802.11 base
Hi Hesham, James, Jim,
I think that the advantages of Opti-DAD
particularly are that there's no dependence
on support in Router infrastructure
(beyond existing ND).
With FastRA, the amount of state kept and the
required code changes are miniscule
(was an afternoon's work for the prototype,
includ
James,
> Do you anticipate that the changes in FMIPv6 for access
> routers will be in all
> IPv6 routers?
=> I don't know. But I know that any router can be
an "access router". People don't develop a special router
because it will be connected to an ethernet that has a an
802.11 base sta
m" <[EMAIL PROTECTED]>;
"Thomas Narten" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, October 29, 2002 10:08 AM
Subject: RE: Changing RS Reply Timing for Mobile IPv6
>
> > I hear your concerns quite clearly.
> >
> > One p
> -Original Message-
> From: James Kempf [mailto:kempf@;docomolabs-usa.com]
> Sent: Tuesday, October 29, 2002 12:39 PM
> To: Bound, Jim; Thomas Narten
> Cc: [EMAIL PROTECTED]
> Subject: Re: Changing RS Reply Timing for Mobile IPv6
>
>
> Hi Jim,
>
&
the ADs, MIP WG chairs, and MIP WG.
>
> How does that sound?
>
> jak
>
> - Original Message -
> From: "Bound, Jim" <[EMAIL PROTECTED]>
> To: "James Kempf" <[EMAIL PROTECTED]>; "Thomas Narten"
> <[EMAIL PROT
c: <[EMAIL PROTECTED]>
Sent: Tuesday, October 29, 2002 7:39 AM
Subject: RE: Changing RS Reply Timing for Mobile IPv6
> James,
>
>Determination of
>how this router is designated is outside the scope of this
>document. An RA that i
James,
Determination of
how this router is designated is outside the scope of this
document. An RA that is immediately unicast to the sender rather
than delayed is known as a "fast RA".
I do not believe it should be outside the scope of this dr
: "James Kempf" <[EMAIL PROTECTED]>
To: "Bound, Jim" <[EMAIL PROTECTED]>; "Brett Pentland"
<[EMAIL PROTECTED]>; "Thomas Narten" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, October 17, 2002 1:40 AM
Subject: Re: Cha
]
Subject: Re: Changing RS Reply Timing for Mobile IPv6
Jim,
We have numbers for standard MIPv6 v.s. optimized MIPv6, where optimized
uses the 802.11 reassociate for a link up trigger to cause the RS. There
is a substantial decrease in packet loss, on the order of the router
beacon. This requires
"Thomas Narten" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, October 16, 2002 8:19 AM
Subject: RE: Changing RS Reply Timing for Mobile IPv6
> James,
>
> Have you actually tested this with implementation? Or is this
> theoretical debate?
>
> T
RS Reply Timing for Mobile IPv6
Thomas,
> Seems to me then that this document is a bit narrowly scoped and may
> even miss the point. Don't we need to look at the overall problem and
> then see what can be done to address the overall problem adequately?
> In general, I don&#x
ED]>
Sent: Tuesday, October 15, 2002 10:20 PM
Subject: Re: Changing RS Reply Timing for Mobile IPv6
>
> Hi James,
>
> I guess you mean draft-mkhalil-ipv6-fastra-01.txt ?
>
> Greg Daley
>
> jak wrote:
> > So the deployment alternative with ND as
Hi James,
I guess you mean draft-mkhalil-ipv6-fastra-01.txt ?
Greg Daley
jak wrote:
> So the deployment alternative with ND as defined in RFC 2461 and the base FMIPv6
> document if one wants faster 802.11 handovers is to set
> MAX_RTR_SOLICITATION_DELAY to zero and set MAX_RA_DELAY_TIME to zer
Thomas,
> Seems to me then that this document is a bit narrowly scoped and may
> even miss the point. Don't we need to look at the overall problem and
> then see what can be done to address the overall problem adequately?
> In general, I don't know that its all that useful to focus on a narrow
>
Hi Alper,
I know it's a risk, especially in Mobile-ip6 case,
but the implementation which we're using (mipl)
doesn't de-configure existing addresses when it
receives an advertisement from a new prefix.
The address is not fully deprecated until the
advertisement lifetime expires.
I'm illustrating
er E. YEGIN" <[EMAIL PROTECTED]>
To: "Richard Nelson" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Cc: "Thomas Narten" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, October 12, 2002 10:11 AM
Subject: Re: Changing RS Reply Timing for Mob
;Richard Nelson"
> <[EMAIL PROTECTED]>
> Cc: "Thomas Narten" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Saturday, October 12, 2002 4:15 AM
> Subject: Re: Changing RS Reply Timing for Mobile IPv6
>
>
> > Greg,
> >
> > >
To: <[EMAIL PROTECTED]>; "Richard Nelson"
<[EMAIL PROTECTED]>
Cc: "Thomas Narten" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, October 12, 2002 4:15 AM
Subject: Re: Changing RS Reply Timing for Mobile IPv6
> Greg,
>
> > I'd just
Greg,
> I'd just like to indicate that we have seen the delay
> for router advertisement to be a significant delay
> in MIPv6 handovers, since there is no DAD in the case
> where a mobile node moves back to a previously visited
> network.
How is that so? Of course the chances of some other
node
Hi Richard & Thomas
I'd just like to indicate that we have seen the delay
for router advertisement to be a significant delay
in MIPv6 handovers, since there is no DAD in the case
where a mobile node moves back to a previously visited
network.
In this case, the RS/RA delay is the biggest factor
i
- Original Message -
From: "Thomas Narten" <[EMAIL PROTECTED]>
>
> Stepping back for a minute. MAX_RA_DELAY_TIME is .5 seconds. A router
> delays a random amount of time between 0 and .5 seconds before
> responding. So, on average, .25 seconds. That's not a terribly long
> delay. What exa
> Certainly obtaining router information is only one part of the problem
> and as you pointed out, the one second delay for DAD is a greater
> problem. From a mobile IPv6 point of view, there is also the problem of
> completing binding updates with home agents or correspondant nodes that
> are a
> In summary, the draft amends RFC 2461 to allow at most one router on
> a link to reply immediately to an RS instead of waiting a random
> amount of time between 0 and MAX_RA_DELAY_TIME. The router is
> allowed to reply to at most MAX_FAST_RAS since the last unsolicited
> multicast is sent. If th
Hi Vlad,
Vladislav Yasevich wrote:
> Greg
>
> Greg Daley wrote:
>
>> Hi Vlad,
>>
>> I'm not sure that there is a requirement to use a fastra flag.
>>
>> There may be situations where multiple nodes come up on a link
>> in the duration between multicast advertisements but this may be
>> handled
Hi Brett
Thanks for your kind comment.
As you may know, random delay of RS is 'to alleviate congestion'
as the following states:
" This serves to alleviate congestion when
many hosts start up on a link at the same time, such as might happen
after recovery from a power failure."
Therefore, we
Title: RE: Changing RS Reply Timing for Mobile IPv6
I'm not sure that we are loosening that. The rest of the quoted
paragraph reads:
"If a host has already performed
a random delay since the interface became (re)enabled (e.g., as part
of Duplicate Address
> > I'm not sure that we are loosening that. The rest of the quoted
> > paragraph reads:
> >
> > "If a host has already performed
> >a random delay since the interface became (re)enabled (e.g., as part
> >of Duplicate Address Detection [ADDRCONF]) there is no need to delay
> >again
> I'm not sure that we are loosening that. The rest of the quoted
> paragraph reads:
>
> "If a host has already performed
>a random delay since the interface became (re)enabled (e.g., as part
>of Duplicate Address Detection [ADDRCONF]) there is no need to delay
>again before sendin
Greg
Greg Daley wrote:
> Hi Vlad,
>
> I'm not sure that there is a requirement to use a fastra flag.
>
> There may be situations where multiple nodes come up on a link
> in the duration between multicast advertisements but this may be
> handled by the MAX_FAST_RAS being set high enough to handl
Hi
James Kempf wrote
> If the mobile node is
> capable of detecting when the link changes, it can immediately send an RS rather
> than wait for a multicast RA.
According to RFC 2461, mobile host should not send RS immediately. Before sending
RS, it should execute random delay like below.
"Be
Hi Vlad,
I'm not sure that there is a requirement to use a fastra flag.
There may be situations where multiple nodes come up on a link
in the duration between multicast advertisements but this may be
handled by the MAX_FAST_RAS being set high enough to handle this.
In the case where many nodes c
lt;[EMAIL PROTECTED]>
Sent: Tuesday, October 08, 2002 10:28 AM
Subject: Re: Changing RS Reply Timing for Mobile IPv6
> James
>
> I think that the draft is missing a trigger mechanism for a fast RA
> response. What I mean is, that if any node not requiring a fast RA
> joins the link,
James
I think that the draft is missing a trigger mechanism for a fast RA
response. What I mean is, that if any node not requiring a fast RA
joins the link, it will use up a fast RA that will potentially cause
delays for a node that would really like a fast answer.
You could take one of the res
37 matches
Mail list logo
