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

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 22 Apr 2008 12:26:39 -0700 (PDT)

Rajeev,
  As Fig. 3 shows, Hi/Hack is optional. The only use of it so far appeared in the extension draft and there I think it is not optional  so a contradiction right there.
  It would serve us better to remove this optional exchange from the base protocol and let the extensions define their own exchange.
  It is so simple like abc.

Regards,

Behcet

----- Original Message ----
From: "Koodli, Rajeev" <[email-masked]>
To: Behcet Sarikaya <[email-masked]>; Rajeev Koodli <[email-masked]>
Cc: [email-masked]
Sent: Friday, April 18, 2008 3:51:20 PM
Subject: Re: [Mipshop] I-D Action:draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt

<!--

 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;text-decoration:underline;}
pre
	{margin:0in;margin-bottom:.0001pt;font-size:10.0pt;font-family:"Courier New";}
span.EmailStyle18
	{font-family:Arial;color:navy;}
 _filtered {margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{}
-->
Behcet,
   
 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 thehandover is already finished. How come PAR would send a HANDOVER INITIATE messageto NAR? 
 [RKo:>]  I don’t see the
correlation between the text in 6.2.1 you cited above and the above sentence. The
handover is not over when PAR processes FBU! NAR may wish to be certain that it
can forward packets to NCoA based on the HI message from PAR which it trusts. PAR
can send HI when it receives FBU regardless of predictive or reactive modes.
This has been the case since RFC 4068. If you had any issues with it, you
should have brought it up when we were resolving the issues.
 
Clearly the purpose of the exchange in Fig. 3 is context transfer and it shouldbe made explicit ONLY in the extension document that needs it.
 [RKo:>] There are many reasons to do
HI/Hack. Please read the protocol fully. For instance, look at the last
paragraph in Section 3.1.
  
The basics of protocol engineering requires us to not to repeat an exchangelike Hi/HAck anywhere we like.

 [RKo:>] Perhaps you should read the
protocol again. I am not going to answer these speculations. 
 Thanks,
 -Rajeev 
 
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 Aprilfool'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 aroundsince RFC 4068.
See " When the source IP address ofthe FBU is not PCoA, i.e., the FBU is sent from the NAR's link, the HI message MUST have a Codevalue of 1; see Section 6.2.1." in paragraph that starts with "After a PrRtAdvmessage is processed.." in Section 4, RFC 4068. Section 6.2.1 discussesusing 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 newmessages 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 andHandoff 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: Tue, 22 Apr 2008 13:04:11 -0700

Behcet,

2008/4/22 Behcet Sarikaya <[email-masked]>:

> Rajeev,
>   As Fig. 3 shows, Hi/Hack is optional. The only use of it so far appeared
> in the extension draft and there I think it is not optional so a
> contradiction right there.
>

Figure 3 says "HI/HAck if necessary". If some extension draft finds it
necessary, so be it. There is no contradiction.

>   It would serve us better to remove this optional exchange from the base
> protocol and let the extensions define their own exchange.
>

As I have said few times already, the HI/HAck exchange in reactive case has
been there since RFC 4068. I cannot remove this at this stage! (We have
followed a process in revising RFC 4068, in case it is not clear to you)

abc or xyz, this is my last response! :-)

-Rajeev

> Subject: Re: [Mipshop] I-D
> Action:draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt
>
>  Behcet,
>
>
>
>    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?
>
> *[RKo:>]  I don't see the correlation between the text in 6.2.1 you cited
> above and the above sentence. The handover is not over when PAR processes
> FBU! NAR may wish to be certain that it can forward packets to NCoA based on
> the HI message from PAR which it trusts. PAR can send HI when it receives
> FBU regardless of predictive or reactive modes. This has been the case since
> RFC 4068. If you had any issues with it, you should have brought it up when
> we were resolving the issues.*
>
>
> 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.
> **
>
> *[RKo:>] There are many reasons to do HI/Hack. Please read the protocol
> fully. For instance, look at the last paragraph in Section 3.1.*
>
> * *
>
> The basics of protocol engineering requires us to not to repeat an
> exchange like Hi/HAck anywhere we like.
>
>  *[RKo:>] Perhaps you should read the protocol again. I am not going to
> answer these speculations. *
>
> *Thanks,*
>
> *-Rajeev *
>
>
> Regards,
>
> Behcet
>
>
> **
>
> 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
> 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.
>
> This draft is a work item of the Mobility for IP: Performance, Signaling
> and Handoff Optimization Working Group of the IETF.
>
>
>     Filename        : draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt
>     Pages          : 48
>     Date            : 2008-04-17
>