Subject: MIPv6 and ND value changes

From: Pekka Savola <[email-masked]>
Date: Tue, 19 Nov 2002 03:40:59 +0200 (EET)

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.

These should be in a separate document, either:
 - by mobileip, reviewed by ipv6 wg
 - by ipv6 wg
 (- waiting for the ND spec revising is probably not an option)

Such a document could be quite short, and probably could be pushed quick 
through the IETF process.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Tue, 19 Nov 2002 04:05:03 +0200 (EET)

> making all of these assumptions to e.g. Neighbor Discovery timer values.

s/assumptions/arbitrary changes/
 
shouldn't be writing quickly under sporadic network connectivity :-(

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Nov 2002 03:35:05 +0100 (CET)

> 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 concerned that implementors for IPv6 routers, which don't otherwise
implement MIPv6, will find these pieces deep inside the MIPv6 specification.
I think these things are more likely to be widely implemented if
they live in a separate and shorter RFC.
Also, we are likely to discover additional optimizations that might help
with mobility and having a set of small specific extensions and/or
modifications around ND or other protocols seems like a quicker way to make
progress on these things.

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.

   Erik

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 18 Nov 2002 19:16:50 -0800

Pekka Savola wrote:

> s/assumptions/arbitrary changes/

on the contrary, they have been well thought out and discussed
on the MIPv6 mailing list. take a look at the changes first.

for example RFC 2462 says if DAD fails, the node SHOULD disable 
the interface. MIPv6 says if DAD fails, generate a random 
interface ID and try again. take a look at the following URL 
for the discussion.

http://www.piuha.net/~jarkko/publications/mipv6/issues/issue79.txt

can you give me one good reason why this change that MIPv6 
recommends is arbitrary? come on.....

Vijay

---

From: Pekka Savola <[email-masked]>
Date: Tue, 19 Nov 2002 05:32:02 +0200 (EET)

> recommends is arbitrary? come on.....

This isn't MIPv6 specific.

One could say this case if only relevant if you use manually configured
care-of addresses (that is, clashes are not so rare that you need to, in
practise, care about them).  Oh you don't assign them manually?  Forget
about it then.

It's a good enhancement, but doen't belong in the MIPv6 spec.

btw. "arbitrary" was a bit strong word; I should have said "substantial".

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 18 Nov 2002 20:01:00 -0800

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 Mobile IPv6
specification in this particular way are not logically valid.  I will try to make

this clear in what follows.

> Even though I think the current ND changes in the MIPv6 spec make sense,

Thank you.

> implement MIPv6, will find these pieces deep inside the MIPv6 specification.

I'm concerned for implementers of systems that want to support Mobile IPv6.
When the specifications are rewritten for all routers, then at that time the
revised specificatoin needs to take the Mobile IPv6 specification into account.
This would completely resolve your fear.  It could be that the new specification
would make some parameter settings conditional on whether or not the routers
are expected to provide support for the attachment of mobile nodes.

> they live in a separate and shorter RFC.

That is trying to predict the future in a very dangerous way.  Your statement
would only be true if no one tried to put any other features in there.  The
discussion about optimistic DAD, for instance, might take months.  I have
no faith that such a document would progress rapidly.  Look at the flow-lable
specification for example...

> progress on these things.

That has no bearing on the immediate problem.  In fact, I would suggest that
the attempt, while praiseworthy, would have exactly the effect of slowing down
this one crucial piece of parameter specification.,

> to revise the specifications along the standards track etc.

Most of the things suggested do not break the specification.  Eliminating the
possibility for faster advertisements does.  This has been shown, and work
with faster advertisements has been done many times.

The discussion has already been made in the IPng working group from years
ago, and nothing has happened to warrant this particular change.  There is no
justification for it.  Anything that has to be done in a more general setting
would
still be quite well able to be done in the more general setting, regardless of
what
goes into the Mobile IPv6 specification.

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 19 Nov 2002 04:37:11 -0800

Vijay,

I think the issue isn't whether this particular optimization is important or
not. The issue is whether we should leave it in the base spec or put it into a
spec with all the other ND optimization bits.

            jak

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Nov 2002 14:07:14 +0100 (CET)

> 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 trying to make it better will further delay the MIPv6 
specification makes me not want to bring up those issues.

   Erik

---

From: Thomas Narten <[email-masked]>
Date: Tue, 19 Nov 2002 08:22:08 -0500

Charlie,

> for having faster router advertisements does not give sensible

Noone is arguing that the possibility for having faster RA should be
eliminated, at least as far as I know.

It is not, IMO, critical that these changes be in the same document as
the base MIPv6 spec. What is important that these ND changes become an
RFC within a reasonable amount of time, so that those that implement
MIPv6 also pick up the ND changes in the same general time frame. I
see no reason why this can't happen within 6 months.

Thomas

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 19 Nov 2002 06:16:25 -0800

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 possibly take away anything
from the future to have things working sensibly in the
present time.

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 19 Nov 2002 06:23:45 -0800

Hello Thomas,

You seem to be concerned that if we change this value in
the base Mobile IPv6 specification, then suddenly it won't
make as much sense to change it or otherwise specify it
in a future ND document.  I think that it patently untrue.
So, I strongly believe that we can have a good base Mobile
IPv6 specification that works, without impeding future progress
on more general ND solutions.  Why not?

> eliminated, at least as far as I know.

Then let's keep a sentence in the specification that makes this plain.
It would not impede progress on ND.

> the base MIPv6 spec.

It is critical for the one change for frequency of router advertisement.

> What is important that these ND changes become an

I think 6 days would be better for the particular point about
router advertisement.  I'm classifying that differently, because it
is required for sensible implementations.

If you want that one in a separate document, then I can have it
for you on Saturday.  I'm concerned, though, that the document
would be viewed as a place to put other things that aren't so
plainly required.

Regards,
Charlie P.

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 19 Nov 2002 11:36:15 -0500

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 much time to
be effective.  Yes, there are better ways to do this and once
they are specified, they can be implemented and deployed.
However, without decent movement detection, the base spec is
incomplete.

On the other hand, other changes (such as what to do on DAD
collision) apply to more the just mobility cases and would
provide greater benefit as separete specs.

Just my $0.02

-vlad
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 19 Nov 2002 09:36:28 -0800

Jim,

if you read my mail again, it was specifically a reply to Pekka.
he called the changes arbitrary. that was really wrong.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Nov 2002 18:04:29 +0200

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 all optimistic DAD
ideas to a separate work item.

For the constants: It seems like there's agreement that optimizations
are needed. There is some disagreement about the type of most efficient
optimizations. There's a big disagreement about where the optimizations
should be done and when.

The practical effect of these constants is that they affect the
efficiency of movements. In particular:
  - If there are no indications from lower layers, it becomes
    slower to detect movement; from few tenths of a second to
    a second or several seconds. This has an impact to user
    perception, as well as TCP behaviour etc.
  - When there is an indication from lower layers, RA rate
    limitation may prevent sending RAs to all-nodes multicast
    address for many simultaneously moving mobiles. The net effect
    of this is slower establishment of communications for the
    mobile on the new link.

As a result, most folks feel that we need new constant values
that support mobility better. So: the issue isn't really about
doing the optimizations or not, but where it is done. We have
the following alternatives for moving forward on this issue:

     1. Specify new constant values in Mipv6 spec. End of story.
        This is the approach taken in draft-mobileip-ipv6-19.txt.
     2. Specify new constant values in Mipv6 spec, but start
        also an activity to come up with a separate constant
        adjustement document (either in MIP or IPv6 WGs). The
        document could specify just new constants, or it could
        also be a more general RA optimizations document, including
        other speed-up mechanisms.
     3. Remove constant modifications from Mipv6 specification,
        and start an activity to come up with a separate constant
        adjustment document. This is the suggestion from the ADs.

The following issues should be taken in account when deciding
which alternative to pick:

- Agreeing on the constant changes in draft 19 might delay
   Mipv6 specification. This includes the need to agree with
   the ADs that the constants belong to this document.

- The creation of a separate document will take in account additional
   viewpoints and may thus consume some amount of time.

- Some implementers have announced that they want solutions now
   for their products.

- It is possible to use indications from lower layer to speed
   up movements, and this is in general more efficient than IP
   layer frequent multicast messages.

- On the other hand, not all link layers and driver firmware
   support indications from lower layers.

- Also, lower-layer information does not help the effect of
   the RA rate limitation rules.

- The constant modifications are really needed for all routers,
   not just MNs and HAs. A separate document may speed up adoption
   of these changes.

- A separate specification makes it easier to update the
   constants as we learn new optimizations.

- There are existing concerns about the suggested constants
   (such as token-bucket proposal) which would be easier to
   discuss if it wouldn't be holding up the Mipv6 specification.

Jari