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

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 18 Apr 2008 12:48:36 -0700 (PDT)

This is the text from 6.2.1:
The Handover Initiate (HI) is an ICMPv6 message sent by an Access
   Router (typically PAR) to another Access Router (typically NAR) to
   initiate the process of a MN's handover.In reactive mode the handover is already finished. How come PAR would send a HANDOVER INITIATE message to NAR? 

Clearly the purpose of the exchange in Fig. 3 is context transfer and it should be made explicit ONLY in the extension document that needs it.

The basics of protocol engineering requires us to not to repeat an exchange like Hi/HAck anywhere we like.

Regards,

Behcet

----- Original Message ----
From: Rajeev Koodli <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: [email-masked]
Sent: Friday, April 18, 2008 11:33:43 AM
Subject: Re: [Mipshop] I-D Action:draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt

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

  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: David Cypher <[email-masked]>
Date: Fri, 18 Apr 2008 16:09:09 -0400

At 03:48 PM 4/18/2008, Behcet Sarikaya wrote:
>    initiate the process of a MN's handover.In reactive mode the 
> handover is already finished. How come PAR would send a HANDOVER 
> INITIATE message to NAR?

There might still be data packets arriving at the PAR for the mobile 
node.  In reactive mode the MN sends the FBU to the PAR via the NAR 
to tell the PAR to establish the tunnel with the NAR using the HI/Ack 
exchange.  The result is the same whether predictive of reactive, 
data arriving at the PAR after the mobile node has connected to the 
NAR and prior to the mobile node sending a BU to its home agent.  If 
the mobile node dose not want to receive packets in transit prior to 
the home agent receiving the BU, then there is no need to specify a 
FMIP reactive mode.  Thus this is the reason for reactive mode.

David Cypher

>Clearly the purpose of the exchange in Fig. 3 is context transfer 
>and it should be made explicit ONLY in the extension document that needs it.
>
>On Fri, Apr 18, 2008 at 8:30 AM, Behcet Sarikaya 
><<mailto:[email-masked]>[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.
>
>
>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.
>
>From: "<mailto:[email-masked]>[email-masked]" 
><<mailto:[email-masked]>[email-masked]>
>To: <mailto:[email-masked]>[email-masked]
>Cc: <mailto:[email-masked]>[email-masked]
>This draft is a work item of the Mobility for IP: Performance, 
>Signaling and Handoff Optimization Working Group of the IETF.
>
>
><http://www.ietf.org/internet-drafts/draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt>http://www.ietf.org/internet-drafts/draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt
>
><ftp://ftp.ietf.org/internet-drafts/>ftp://ftp.ietf.org/internet-drafts/
>