Subject: RE: [mobile-ip] AD review commments on draft-ietf-mobileip-ipv6-1 9.txt

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Fri, 15 Nov 2002 00:37:27 +0100

Brett, 

I assume you mean "remove the optimisations from the base spec"
but not "remove any movement detection related protocols" right?

For example, the router advertisement interval option can
remain in the spec, but not the sentence(s) that say that
a MN MAY use a new CoA while doing DAD. 

Is this a correct interpretation of your message?

I think it would be good to remove these minor text(s)
from the spec since they clearly deserve more discussions, 
but things like the router advertisement interval and 
the R bit in the RA should stay IMO.

Hesham 

  > -----Original Message-----
  > From: Brett Pentland [mailto:[email-masked]]
  > Sent: Wednesday, November 13, 2002 4:49 AM
  > To: [email-masked]
  > Cc: Thomas Narten
  > Subject: Re: [mobile-ip] AD review commments on
  > draft-ietf-mobileip-ipv6-19.txt
  > 
  > 
  > 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-optimi
  > stic-dad-00.txt>
  > Fast router advertisements - 
  > <http://www.ietf.org/internet-drafts/draft-mkhalil-ipv6-fast
  > ra-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>
  >

---

From: Brett Pentland <[email-masked]>
Date: Fri, 15 Nov 2002 10:53:08 +1100

Hi Hesham,

Yes, I think your interpretation of my email is correct.  Basically I
was referring to the items outlined in Thomas's email, including things
like changing the minimum router advertisement interval (but not the
router advertisement interval option).

The main point of my email was that if such a process was undertaken,
then this new optimisation document would make a good place to include
some of the other optimisation techniques that have been discussed
lately and allow us to discuss their relative merits, consider side
effects, etc.

Brett.

-- 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Brett Pentland                         [email-masked]
 CTIE - Centre for Telecommunications and Information Engineering
 Department  of  Electrical  and   Computer  Systems  Engineering
 Monash University, VIC, 3800,                          Australia
 Phone : +61 3 9905-5245                    Fax : +61 3 9905-5358
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~