On Tue, 19 Nov 2002, Pekka Savola wrote:
> Hello,
>
> FWIW, I fully support Thomas Narten on his view that MIPv6 should not be
> making all of these assumptions to e.g. Neighbor Discovery timer values.
s/assumptions/arbitrary changes/
shouldn't be writing quickly under sporadic network connec
> FWIW, I fully support Thomas Narten on his view that MIPv6 should not be
> making all of these assumptions to e.g. Neighbor Discovery timer values.
I think this makes sense as well. Let me try to state my reasons.
Even though I think the current ND changes in the MIPv6 spec make sense,
I'm con
The engineers who implemented MIPv6 and there are a few and in the MIPv6
working group are same engineers that do ND in most cases today. The
issue is not one of expertise. This is MIPv6 work not IPv6 work.
/jim
[Honor, Commitment, Integrity]
> -Original Message-
> From: Pekka Savola
gt; Cc: [EMAIL PROTECTED]
> Subject: Re: MIPv6 and ND value changes
>
>
> > FWIW, I fully support Thomas Narten on his view that MIPv6
> should not
> > be
> > making all of these assumptions to e.g. Neighbor Discovery
> timer values.
>
> I think this makes s
> Come on. You can't implement or understand MIPv6 if you don't have ND down.
> It is not even possible.
> The engineers in MIPv6 are clearly qualified to work to enhance ND.
I think I can implement MIPv6 just fine without section 7.5, 7.6, and 7.7
in the MIPv6 draft. After all, I'll have 149-3
Pekka Savola wrote:
>
>
> > FWIW, I fully support Thomas Narten on his view that MIPv6 should not be
> > making all of these assumptions to e.g. Neighbor Discovery timer values.
>
> s/assumptions/arbitrary changes/
on the contrary, they have been well thought out and discussed
on the MIPv6 ma
On Mon, 18 Nov 2002, Vijay Devarapalli wrote:
> > > FWIW, I fully support Thomas Narten on his view that MIPv6 should not be
> > > making all of these assumptions to e.g. Neighbor Discovery timer values.
> >
> > s/assumptions/arbitrary changes/
>
> on the contrary, they have been well thought ou
Hi Erik,
> So while I don't want to slow down the MIPv6 specification or the
> implementation and deployment, I think breaking out these pieces will help
> with specification and protocol modularity, which makes it easier and quicker
> to revise the specifications along the standards track etc.
S
Hello Erik,
I am particularly concerned that we have a Mobile IPv6 specification
that, when implemented, gives sensible results. Eliminating the possibility
for having faster router advertisements does not give sensible results.
However, the stated reasons for wanting to change the existing Mob
Erik,
> > Come on. You can't implement or understand MIPv6 if you
> don't have ND
> > down. It is not even possible. The engineers in MIPv6 are clearly
> > qualified to work to enhance ND.
>
> I think I can implement MIPv6 just fine without section 7.5,
> 7.6, and 7.7 in the MIPv6 draft. Aft
> > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue79.txt
I just want to point out that Francis and Vlad in the above both are
implemetors not rubber neckers and both work in IPv6 WG and MIPv6 WG so
the expertise is in both groups (Thomas this is one example why I think
IPv6 WG is co
i" <[EMAIL PROTECTED]>
To: "Pekka Savola" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, November 18, 2002 7:16 PM
Subject: Re: MIPv6 and ND value changes
> Pekka Savola wrote:
> >
> >
>
> > > FWIW, I fully support Thomas Narten on h
;t. I think it makes some
sense to group these into a seperate spec in the MIP group.
jak
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, November 18, 2002 7:48 PM
Subject: R
> I am particularly concerned that we have a Mobile IPv6 specification
> that, when implemented, gives sensible results. Eliminating the possibility
> for having faster router advertisements does not give sensible results.
I don't want to eliminate it - I want to make it better.
But the fear of t
> So, perhaps my comment is a bit naive, but as the changes have been
> discussed in the MIP WG and many people think the changes are
> sane in the IPv6 WG ... I wonder what would be accomplished by
> breaking them out in a seperate document. Since the IPv6
> WG will be working updating ND, could
Charlie,
> I am particularly concerned that we have a Mobile IPv6 specification
> that, when implemented, gives sensible results. Eliminating the possibility
> for having faster router advertisements does not give sensible
> results.
Noone is arguing that the possibility for having faster RA sho
> Missed my point. You can't implement part of ND for a feature like MIPv6.
> You have to understand ND as a software engineer.
Understood. But there are different boxes that need to implement different
things.
Home agents need to implement the 'H' bit in the RA and the 'R' bit in
the prefix i
Hi James,
> The primary issue is whether the ND spec itself should benefit.
I agree. I think it should. My suggestion is that MIPv6 discusses
what is needed for MIPv6 (maybe even moved into an appendix) and
this data is taken as a starting point for updating 2461.
> The behavior of DAD failu
Hello Erik,
No one should fear making the technology better.
However, having a specification that gives sensible
results does not in any way impede that effort.
If Mobile IPv6 specifies something, that something
can be taken in to account in any future specification.
I can't see how it would possi
, Commitment, Integrity]
> -Original Message-
> From: Erik Nordmark [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 19, 2002 8:07 AM
> To: Charlie Perkins
> Cc: Erik Nordmark; [EMAIL PROTECTED]
> Subject: Re: MIPv6 and ND value changes
>
>
> > I am particularly c
> And the key thing in my opinion is that the (access) routers
> need to implement the faster RA and the advertisement
> interval option. Thus the folks that implement routers need
> to implement all of ND (as software engineers) but they
> probably don't need all of the MIPv6 extensions to ND.
On Tue, 19 Nov 2002 [EMAIL PROTECTED] wrote:
> > By burying the solution for this into the MIP spec, it
> > removes the possibility that wider IPv6 nodes can benefit.
>
> I don't think we should bury it in the MIP spec, but first
> address it in the MIPv6 spec then take that & move it into a
> 24
> Leaving it in the current spec does not remove the potential for
> optimization.
Doing local optimizations to a specification which is 150 pages might be
possible yet it is painful.
> Taking it out may cause MIPv6 to not ship.
Making the RFC not ship? Or making something else not ship?
The
Hello
I belive that some ND changes have to remain in the MIPv6
spec. The ND changes without which the base MIPv6 spec is
incomplete and can not be made to work well should remain in the
spec. An example of this is RA timers. Without faster
RAs, the movement detection algorithm takes way to muc
I'm getting very confused when reading this
discussion. Some people are focusing on the
RA intervals, others about DAD (2462) and
others talk generally about ND.
Please divide the issues...
AFAIK we have the following (independent) issues:
- RA intervals were reduced by MIPv6 (changing 2461)
In your previous mail you wrote:
> > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue79.txt
I just want to point out that Francis and Vlad in the above both are
implemetors ...
=> as my name occurs in this thread where my opinion is nicely represented
by Erik, I often
Cc: <[EMAIL PROTECTED]>
> Sent: Monday, November 18, 2002 7:16 PM
> Subject: Re: MIPv6 and ND value changes
>
> > Pekka Savola wrote:
> > >
> > >
> >
> > > > FWIW, I fully support Thomas Narten on his view that MIPv6 should not be
> &g
Francis,
Francis Dupont wrote:
>
> In your previous mail you wrote:
>
>> > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue79.txt
>
>I just want to point out that Francis and Vlad in the above both are
>implemetors ...
>
> => as my name occurs in this thread where my
"Hesham Soliman (EAB)" wrote:
>
> I'm getting very confused when reading this
> discussion. Some people are focusing on the
> RA intervals, others about DAD (2462) and
> others talk generally about ND.
>
> Please divide the issues...
> AFAIK we have the following (independent) issues:
>
> - RA i
I'm trying to summarize the discussion about the constants. First
I'd like to agree with Hesham: We need to treat the constants,
optimistic DAD, collision detection all as separate items. What I
see is that on most of the issues we are close to consensus, e.g.
I don't think anyone is against moving
On Tue, 19 Nov 2002, Vijay Devarapalli wrote:
> > - RA intervals were reduced by MIPv6 (changing 2461)
> > - When DAD fails we configure a new address and try again (2462)
> > - Elimination of DAD delays (optimistic DAD)
> > - Eliminsation of the random delay before sending an RA (fast RA)
> >
> >
In your previous mail you wrote:
MIPv6 does not say router should send RAs more frequently. it
just says access routers SHOULD be configurable to send RAs
more frequently.
=> We know this is translated in many minds in the first statement...
And this doesn't change the argument that R
Hi Erik,
Sorry to reply so late on this,
The token bucket support indicated in your email
is already specified (and implemented) in FastRA.
In fact, there's not much more than that to the spec
(It is 3 pages).
I don't think that putting FastRA in MIPv6 was an option
proposed by anyone, but I d
> > - RA intervals were reduced by MIPv6 (changing 2461)
> > > - When DAD fails we configure a new address and try again (2462)
> > > - Elimination of DAD delays (optimistic DAD)
> > > - Eliminsation of the random delay before sending an RA
> (fast RA)
> > >
> > > The last two bullets
On Tue, 19 Nov 2002, Hesham Soliman (EAB) wrote:
> => Why do you disagree with 2? Do you think a MN
> should disable an interface when DAD fails the
> first time?
> Sounds disastrous
I don't disagree with the problem (but perhaps with how you treat it), but
let me say it again:
*THERE'S NOTHING
> I don't disagree with the problem (but perhaps with how you
> treat it), but
> let me say it again:
>
> *THERE'S NOTHING MIPV6-SPECIFIC IN THAT*
=> Mobility will increase the minute probability of
collision. Anyway, that's not the point, you're saying
that you disagree with the so
On Tue, 19 Nov 2002, Hesham Soliman (EAB) wrote:
> > I don't disagree with the problem (but perhaps with how you
> > treat it), but
> > let me say it again:
> >
> > *THERE'S NOTHING MIPV6-SPECIFIC IN THAT*
>
> => Mobility will increase the minute probability of
> collision.
Maybe, b
Han wrote:
> I agree with Richard.
> The AP cahed RAs can be esaily implemented and an alternative to fast RAs.
> IMHO, The AP which cache RAs and sends them to an MN at its association with the AP,
> is more deployable approach than router supporting fast RA.
> The change of AP is easier than th
> MIPv6 does not say router should send RAs more frequently. it
> just says access routers SHOULD be configurable to send RAs
> more frequently. this is to be used in the absense of any L2
> help.
Vijay,
One part of the problem I see is that your last sentence above doesn't
appear in the draft
Erik Nordmark wrote:
>
> One part of the problem I see is that your last sentence above doesn't
> appear in the draft. Getting the applicability of the frequent unsolicited
> RAs stated is important.
> Doing this in a short separate draft doesn't have to delay the mipv6
> spec, but working out th
The draft covers this quite well near the end of section 7.5. It talks
specifically about low bandwidth networks which maybe could be expanded
to include any network where L2 support is available, but I think the
intent is pretty clear.
Richard.
Erik Nordmark wrote:
>
> > MIPv6 does not say
So I listened to this argument for a very long
time (too long) yesterday wondering what on earth
the big deal was. I still don't get it. If people
want to dial up the ND rate, it only hurts their
link. There's no greater internet impact that I
can see. If it's taking up too much bandwidth, a
sniff
In your previous mail you wrote:
So I listened to this argument for a very long
time (too long) yesterday wondering what on earth
the big deal was. I still don't get it. If people
want to dial up the ND rate, it only hurts their
link. There's no greater internet impact that I
Hello Francis,
Francis Dupont wrote:
> I agree but I have a concern to get this in an unclear spec,
> i.e., as a network manager, I'd not like to get request to put
> silly RA timing because it is written somewhere.
We certainly don't want an unclear specification. And, if a
network manager ne
In your previous mail you wrote:
We certainly don't want an unclear specification. And, if a
network manager needs to support mobile nodes on any
local domains, that network manager needs in many circumstances
to have the information that running more frequent advertisements
is ad
Francis Dupont wrote:
> => last chance solutions should be marked and never get more than
> a MAY.
Indeed, the frequency parameter is tunable. There is no specification
that one HAS to use the advertisement as a beacon. You should only
do this if it is suitable for your networks. You MAY us
2002 8:52 am
Subject: RE: MIPv6 and ND value changes
> I'm getting very confused when reading this
> discussion. Some people are focusing on the
> RA intervals, others about DAD (2462) and
> others talk generally about ND.
>
> Please divide the issues...
> A
On Tue, Nov 19, 2002 at 10:37:33AM -0800, Richard Nelson wrote:
>
> I'd add the minor points that section 11.5.2 contains
> a basic version of optimistic
> DAD (its been there since draft 12) [...]
Basic? ... Very Basic!
"Furthermore, the mobile node MAY continue using the
addr
Richard wrote :
> I'd add the minor points that section 11.5.2 contains a basic version of optimistic
> DAD (its been there since draft 12) and that there AP cached RAs are an
> alternative to fast RAs in yet another separate draft.
I agree with Richard.
The AP cahed RAs can be esaily im
er 19, 2002 4:05 PM
Subject: Fw: RE: MIPv6 and ND value changes
> Richard wrote :
>
> > I'd add the minor points that section 11.5.2 contains a basic version of
optimistic
> > DAD (its been there since draft 12) and that there AP cached RAs are an
> > alternative to
James Kempf worte:
> The problem with this proposal is that the AP doesn't exist as far as IETF is
> concerned. An AP is not an IP device, and it is not on the map as far as the
> Internet architecture is concerned.. Routers do exist and therefore the fast RA
> could be standardized in the IETF.
>
> > The problem with this proposal is that the AP doesn't exist as far as IETF
is
> > concerned. An AP is not an IP device, and it is not on the map as far as the
> > Internet architecture is concerned.. Routers do exist and therefore the fast
RA
> > could be standardized in the IETF.
> >
> > That
James Kempf wrote:
> >
> > as i know, there are two 802.11 deployments : with relays APs and with
> integrated AP/AR.
> > thus, i think this proposal(APs cache RAs) can be considered in IETF if
> 802.11 deployments with "integrated AP/AR" is considered. what do you think?
> >
>
> If the AP and A
; <[EMAIL PROTECTED]>
To: "Youn-Hee Han" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, November 21, 2002 8:28 AM
Subject: Re: MIPv6 and ND value changes
> Han wrote:
>
> > I agree with Richard.
> > The AP cahed RAs can be esaily imp
54 matches
Mail list logo
