Subject: [Mipshop] Comments on draft-ietf-mipshop-fh80216e-03.txt

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 05 Nov 2007 16:49:45 -0800

Hello,

I have a few comments on draft-ietf-mipshop-fh80216e-03.txt.

The document relies on 802.21 primitives being available. I think
it should be possible to use FMIPv6 over 802.16e link even when
802.21 primitives are not implemented. We could describe the
handover procedure using some abstract L2 notification events. I
am not suggesting removing 802.21 related stuff from the document,
but describe FMIPv6 handovers both with and without 802.21.

In section 5.2, there is some confusion in the text. It is not
clear if the LHI message triggers the FBU or the other way around.
Figure 3 shows this clearly, with the LHI message triggering the
FBU. But there is some text in section 5.2 that says something
otherwise. See below.

> After receiving either MOB_BSHO-RSP or
>    MOB_BSHO-REQ message, the MN sends an FBU (Fast Binding Update) to
>    the PAR.  When the response, an FBack message, arrives at the MN, the
>    Link_Handover_Imminent (LHI) is used to signal the IP layer of the
>    arrival of MOB_BSHO-REQ/MOB_BSHO-RSP in the link layer as soon as
>    possible. 

In Figure 3, it is shown that MOB_HO-IND triggers the PAR to
forward packets to the NAR.

>     7.    |------------------FBU---------------->|            |      |
>           |      |                        |      |-----HI---->|      |
>           |      |                        |      |<---HACK----|      |
>           |<-----------------FBack---------------|-->         |      |
>     8.    |(HC)->|-------MOB_HO-IND------>|  forward pkt=====>|      |

But according to 4068bis, the FBU/FBAck exchange coupled with
the HI/HACK exchange triggers the forwarding. If that behavior
is being modified, it should be explicitly pointed out.

Finally the document is missing the IANA considerations section.
Even if there are no IANA assignment requests, the document
should contain an IANA considerations section that says nothing
is being requested of IANA. Otherwise the document will not pass
the idnits check.

Vijay

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 7 Nov 2007 07:00:37 -0800 (PST)

Hi Heejin,
  Regarding Section 7, as I mentioned before, it would be better to remove this section completely. I remember when we asked you to modify Section 3 in version 01 so that it includes point to point link discussion properly, you had preferred to remove that section. 
  I don't understand why this section has been added? The text you have is confusing and not correct in some places. Prefix management will be dealt with after rechartering on the base protocol level. So the idea is not to deal with this in the individual link handover documents like 16e and 3GPP2.
  Regards,

Behcet

----- Original Message ----
From: Heejin Jang <[email-masked]>
To: Vijay Devarapalli <[email-masked]>
Cc: Mipshop <[email-masked]>
Sent: Wednesday, November 7, 2007 12:25:59 AM
Subject: [Mipshop] Re: Comments on draft-ietf-mipshop-fh80216e-03.txt

Hi Vijay.

Thank you for your valuable feedback.
Kindly see the inline comments.

On 11/6/07, Heejin Jang <[email-masked]> wrote:
> The document relies on 802.21 primitives being available. I think it
> should be possible to use FMIPv6 over 802.16e link even when
> 802.21 primitives are not implemented. We could describe the handover
> procedure using some abstract L2 notification events. I am not
> suggesting removing 802.21 related stuff from the document, but
> describe FMIPv6 handovers both with and without 802.21.

It sounds good, but actually without the support of 802.21, we simply
need to implement the primitives which can play the same
functionality. We will add the below mention in the draft.

"This document assumes that the mobile node is equipped with the MIH
(Media Independent Handover) technology proposed by IEEE 802.21 WG and
it can benefit from the existing MIH primitives for the fast handover.
In case the MIH is not deployed in the MN, it is necessary to
implement a set of primitives proposed in this document
independently."

> In section 5.2, there is some confusion in the text. It is not clear
> if the LHI message triggers the FBU or the other way around.
> Figure 3 shows this clearly, with the LHI message triggering the FBU.
> But there is some text in section 5.2 that says something otherwise.
> See below.

Right. This is the same comment given from Ved, and we fixed it as
 follows.

"After receiving either a MOB_BSHO-RSP or a MOB_BSHO-REQ message, the
MN triggers the Link_Handover_Imminent (LHI) in order to signal the IP 
layer of the arrival of MOB_BSHO-REQ/MOB_BSHO-RSP in the link layer as
soon as possible. On receiving the LHI, the IP layer sends an FBU to
the PAR."

> In Figure 3, it is shown that MOB_HO-IND triggers the PAR to forward
> packets to the NAR.
>
> >           |      |                        |      |-----HI---->|    
  |
> >           |      |                        |      |<---HACK----|    
  |
> But according to 4068bis, the FBU/FBAck exchange coupled with the
> HI/HACK exchange triggers the forwarding. If that behavior is being
> modified, it should be explicitly pointed out.

Ok. The figure seems to be misleading. The packet forwarding at PAR
happens before the MN issues an MOB_HO-IND message. We fixed the
figure as follows.

   7.    |------------------FBU---------------->|            |      |
         |      |                        |      |-----HI---->|      |
         |      |                        |      |<---HACK----|      |
         |<-----------------FBack---------------|-->         |      |
         |      |                        |  forward pkt=====>|      |
   8.    |(HC)->|-------MOB_HO-IND------>|      |            |      |

> Even if there are no IANA assignment requests, the document should
> contain an IANA considerations section that says nothing is being
> requested of IANA. Otherwise the document will not pass the idnits
> check.

Ok. We added a Section for IANA as below.

"9.  IANA Considerations

This document does not require any new number assignment from IANA"

- Best Regards,
Heejin

---

From: Heejin Jang <[email-masked]>
Date: Thu, 08 Nov 2007 06:51:50 +0000 (GMT)

Ok. 
I will modify the text as Rajeev suggested. 
 
- Best Regards, 
Heejin.

------- Original Message -------
Sender : Vijay Devarapalli<[email-masked]>
Date   : 2007-11-08 08:13 (GMT+09:00)
Title  : Re: [Mipshop] Re: Comments on draft-ietf-mipshop-fh80216e-03.txt

Rajeev Koodli wrote:
> Hi Heejin,
> 
> 
> On 11/6/07 10:25 PM, "ext Heejin Jang" <[email-masked]> wrote:
> 
>> Hi Vijay.
> 
> I agree with Vijay. Even the suggested text above assumes that the "..
> Mobile node is equipped with MIH technology". This should be re-worded.
> Suggested text below:
> 
> "In order to maximize the benefits of synchronizing link layer handover with
> the fast IP handover procedure, it may be useful to exploit the link-layer
> handover indicators when available. For example, the Media Independent
> Handover (MIH) services being defined in the IEEE 802.21 working group could
> be used for this purpose, as are link-layer specific indicators (when they
> are available)."

Yes, this is what I was getting at. It needs to be made clear that
802.21 primitives are not a MUST for using FMIPv6 over 802.16e links.

Vijay

---

From: Heejin Jang <[email-masked]>
Date: Thu, 08 Nov 2007 07:42:13 +0000 (GMT)

Hi, Sarikaya
 
As described in Section 5.3 in RFC4068bis, FMIPv6 operation works regardless of 
the prefix management.   
"As defined in Section 2, the Prefix part of ``AR-Info'' is the prefix   valid on the interface 
to which the AP is attached.  This document   does not specify how this Prefix is managed,
 it's length and   assignment policies.  The protocol operation specified in this   document works 
regardless of these considerations." 

The proposed scheme is based on FMIPv6, therefore it is also independent of the link-model 
and the prefix management scheme, which I intended to specify in Section 7 in the fh80216e draft.

Anyway I'll delete the Section 7 because what I'd like to say is  exactly the same as Section 5.3 in RFC4068bis.
 
- Best Regards, 
Heejin

------- Original Message -------
Sender : Behcet Sarikaya<[email-masked]>
Date   : 2007-11-08 00:00 (GMT+09:00)
Title  : Re: [Mipshop] Re: Comments on draft-ietf-mipshop-fh80216e-03.txt

Hi Heejin,

Behcet

----- Original Message ----
From: Heejin Jang <[email-masked]>
To: Vijay Devarapalli <[email-masked]>
Cc: Mipshop <[email-masked]>
Sent: Wednesday, November 7, 2007 12:25:59 AM
Subject: [Mipshop] Re: Comments on draft-ietf-mipshop-fh80216e-03.txt

Hi Vijay.

> >    arrival of MOB_BSHO-REQ/MOB_BSHO-RSP in the link layer as soon as

Right. This is the same comment given from Ved, and we fixed it as follows.

"9.  IANA Considerations

- Best Regards,
Heejin

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 8 Nov 2007 07:20:59 -0800 (PST)

Comments inline.

Regards,

Behcet

----- Original Message ----
From: Heejin Jang <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: Mipshop <[email-masked]>
Sent: Thursday, November 8, 2007 1:42:13 AM
Subject: Re: Re: [Mipshop] Re: Comments on draft-ietf-mipshop-fh80216e-03.txt

Hi, Sarikaya
 
As described in Section 5.3 in RFC4068bis, FMIPv6 operation works
 regardless of 
the prefix management.   
"As defined in Section 2, the Prefix part of ``AR-Info'' is the prefix
   valid on the interface 
to which the AP is attached.  This document   does not specify how this
 Prefix is managed,
 it's length and   assignment policies.  The protocol operation
 specified in this   document works 
regardless of these considerations." 

[behcet] Let's not rehash the heated debates we had on this.

The proposed scheme is based on FMIPv6, therefore it is also
 independent of the link-model 
and the prefix management scheme, which I intended to specify in
 Section 7 in the fh80216e draft.

[behcet] 16e link model is already defined Heejin, how can you make it independent of that?

Anyway I'll delete the Section 7 because what I'd like to say is
  exactly the same as Section 5.3 in RFC4068bis.
 
[behcet] Yes, that would be  happy ending 

- Best Regards, 
Heejin

------- Original Message -------
Sender : Behcet Sarikaya<[email-masked]>
Date   : 2007-11-08 00:00 (GMT+09:00)
Title  : Re: [Mipshop] Re: Comments on
 draft-ietf-mipshop-fh80216e-03.txt

Hi Heejin,
  Regarding Section 7, as I mentioned before, it would be better to
 remove this section completely. I remember when we asked you to modify
 Section 3 in version 01 so that it includes point to point link discussion
 properly, you had preferred to remove that section. 
  I don't understand why this section has been added? The text you have
 is confusing and not correct in some places. Prefix management will be
 dealt with after rechartering on the base protocol level. So the idea
 is not to deal with this in the individual link handover documents like
 16e and 3GPP2.
  Regards,

Behcet

----- Original Message ----
From: Heejin Jang <[email-masked]>
To: Vijay Devarapalli <[email-masked]>
Cc: Mipshop <[email-masked]>
Sent: Wednesday, November 7, 2007 12:25:59 AM
Subject: [Mipshop] Re: Comments on draft-ietf-mipshop-fh80216e-03.txt

Hi Vijay.

  |
  |

"9.  IANA Considerations

- Best Regards,
Heejin