Subject: Re: [Mipshop] I-D Action:draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 18 Apr 2008 08:30:10 -0700 (PDT)

Hi Rajeev,
  The concern I raised on Fig. 3 in my mail on April 1st (it was not April fool's joke though ) still remains valid in Version 7. 
  As I mentioned this change was first made in Version 2 right after July 2007 Chicago IETF meeting and it has some links with draft-yokota-mipshop-pfmipv6.
  Please remove this change! The extensions of FMIP can define new messages if needed.

Regards,

Behcet
----- Original Message ----
From: "[email-masked]" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Sent: Thursday, April 17, 2008 8:15:02 AM
Subject: [Mipshop] I-D Action:draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility for IP: Performance, Signaling and Handoff Optimization Working Group of the IETF.

    Title           : Mobile IPv6 Fast Handovers
    Author(s)       : R. Koodli
    Filename        : draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt
    Pages           : 48
    Date            : 2008-04-17

Mobile IPv6 enables a Mobile Node to maintain its connectivity to the
Internet when moving from one Access Router to another, a process
referred to as handover.  During handover, there is a period during
which the Mobile Node is unable to send or receive packets because of
link switching delay and IP protocol operations.  This "handover
latency" resulting from standard Mobile IPv6 procedures, namely
movement detection, new Care of Address configuration, and Binding
Update, is often unacceptable to real-time traffic such as Voice over
IP.  Reducing the handover latency could be beneficial to non-real-
time, throughput-sensitive applications as well.  This document
specifies a protocol to improve handover latency due to Mobile IPv6
procedures.  This document does not address improving the link
switching latency.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop

---

From: "Rajeev Koodli" <[email-masked]>
Date: Fri, 18 Apr 2008 09:33:43 -0700

Hi Behcet,

On Fri, Apr 18, 2008 at 8:30 AM, Behcet Sarikaya <[email-masked]>
wrote:

> Hi Rajeev,
>   The concern I raised on Fig. 3 in my mail on April 1st (it was not April
> fool's joke though ) still remains valid in Version 7.
>

:-)

>   As I mentioned this change was first made in Version 2 right after July
> 2007 Chicago IETF meeting and it has some links with
> draft-yokota-mipshop-pfmipv6.
>

This is not accurate. The HI/Hack exchange in the reactive case has been
around since RFC 4068.
See " When the source IP address of the FBU is not PCoA, i.e., the FBU is
sent from the NAR's link, the HI message MUST have a Code value of 1;
see Section
6.2.1." in paragraph that starts with "After a PrRtAdv message is
processed.." in Section 4, RFC 4068. Section 6.2.1 discusses using Code 1
for such a HI/HAck exchange.

Figure 3 is only making this illustrative.

Thanks,

-Rajeev

> This draft is a work item of the Mobility for IP: Performance, Signaling
> and Handoff Optimization Working Group of the IETF.
>
>