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
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 use
: 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 fast RAs in yet another separate draft.
I agree with Richard.
The AP
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 the
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 the
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 said, I
James Kempf wrote:
snip
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 AR are
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
' is no different than having
the router send the RA after the MN has done the reassociation.
Youn-Hee Han.
- Original Message -
From: Pyungsoo Kim [EMAIL PROTECTED]
To: Youn-Hee Han [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, November 21, 2002 8:28 AM
Subject: Re: MIPv6 and ND
]
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 his view that MIPv6 should not be
making all of these assumptions to e.g. Neighbor
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
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 not
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 should
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
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
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
, 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 concerned that we have a Mobile IPv6
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.
I
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
2461-bis
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
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
it in the base spec or put it into a
spec with all the other ND optimization bits.
jak
- Original Message -
From: Vijay Devarapalli [EMAIL PROTECTED]
To: Pekka Savola [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, November 18, 2002 7:16 PM
Subject: Re: MIPv6 and ND value
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 opinion is
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 intervals
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
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)
The last
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
: 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...
AFAIK we have the following (independent) issues:
- RA intervals
- 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 are addressed in
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
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
address
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
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
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
[mailto:[EMAIL PROTECTED]]
Sent: Monday, November 18, 2002 8:41 PM
To: [EMAIL PROTECTED]
Subject: MIPv6 and ND value changes
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
: 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 sense as well. Let me try to state my reasons.
Even though I think the current ND changes
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 mailing
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 out and
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.
So,
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
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. After all,
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
48 matches
Mail list logo
