Subject: Re: [mobile-ip] AD review commments on draft-ietf-mobileip-ipv6-19.txt

From: Thomas Narten <[email-masked]>
Date: Mon, 18 Nov 2002 21:56:30 -0500

Hi Brett.

What you say in your note is precisely what I was thinking. The entire
more general topic of removing potential delays when connecting to a
network, etc., are the topics of a number of drafts and there are
customers other than MIPv6 (e.g., fast handoff work) that want
this. It's also relevant to non-Mobile nodes too. It would be good to:

- discuss the MIP issues  as part of the more general problem

- make sure we make fixes that are applicable to other environments
  than just MIPv6.

- put the changes in a document where it will be easy to actually find
  them  and it is clear that all.

This doesn't have to take a long time. I think it is credible to aim
for getting such a document out in 6 months.  I suspect there will be
broad support for a number of the suggested changes, but some may take
a bit of discussion.

Having a separate document completed in 6 months should not set back
real deployment significantly. Indeed, one of the reasons I think it
makes sense to split of this part is that I worry that leaving it in
may delay getting the core spec done. The ND changes would likely
receive some attention from the IPv6 community during Last Call.

Thomas

> This suggestion to pull the performance optimisations out of the base
> spec and put them into a separate document sounds like a sensible idea,
> especially if they are going to be the really contentious items that
> slow down the progress of the base document.

> There have been a number of optimisations discussed on the list in
> addition to those that are in the MIPv6 draft:

> Optimistic DAD -
> <http://www.ietf.org/internet-drafts/draft-moore-ipv6-optimistic-dad-00.txt>
> Fast router advertisements - 
> <http://www.ietf.org/internet-drafts/draft-mkhalil-ipv6-fastra-02.txt>
> Fast router discovery with AP notification - 
> <http://www.ietf.org/internet-drafts/draft-jinchoi-l2trigger-fastrd-01.txt>
> Duplicate Address Detection Optimization using IPv6 Multicast Listener
> Discovery - 
> <http://www.ietf.org/internet-drafts/draft-daley-ipv6-mcast-dad-01.txt>

> to name a few that leap to my mind (there are probably others)

> This optimisation document sounds like a good place to consolidate these
> techniques, explain their relationships and debate their relative
> merits.

> Any thoughts?
> Brett.

> Thomas Narten wrote:
> > 
> > The WG has requested that this document be advanced. I have reviewed
> > the document and have a number of comments on it. Many are
> > editorial/clarification type questions, which will be sent in a
> > separate note. Here are some of the more general comments I have. My
> > sense is that based on the number of comments and issues, this
> > document is not ready for IETF LC yet. On the other hand, I don't see
> > any real show stoppers, and I've been told that a revised version can
> > be produce fairly quickly, once there is agreement on the needed
> > edits.
> > 
> > I'm not comfortable with text in the document that are basically
> > modifications to ND that are not critical to basic MIP. Some
> > modifications are clearly critical (new message options, etc.) But
> > there are also a number of changes to the ND spec that are of broader
> > applicability than to just mobile nodes. In particular, there is text
> > along the lines of
> > 
> >   - one MAY skip DAD, if one feels like it
> >   - one can send messages more frequently than called for in the ND spec
> >   - one need not delay as long as the ND spec calls for when waiting
> >     to send RS
> >   - run DAD in parallel with using the address (optimistic DAD)
> >   - etc.
> > 
> > See Section 7, and 7.5-7.6 in particular. But the spec also includes
> > language that says if DAD fails, one should generate a new IID and try
> > again. (Section 7.7)
> > 
> > Most, if not all of these changes have not been reviewed by the IPv6
> > WG, AFAIK. I see two ways of handling this:
> > 
> > a) point the IPv6 WG to the document and ask them to
> >    comment/review. But I suspect that this will not be a short
> >    discussion.
> > 
> > b) Pull much or all of this text out of the MIP spec, put it in a
> >    separate ID, and then run it through the process separately (i.e,
> >    don't hold up the MIP spec). I don't think these changes are
> >    critical to MIP in a normative sense. They are optimizations that
> >    will make MIP work better. I think we can target getting a
> >    separate document in about 6 months.
> > 
> > After some preliminary discussion with the MIP and IPv6 chairs, the
> > latter approach seems to be the preferred one.
> > 
> <snip>