Subject: [Mip6] Reply to AD review of mipshop-fh80216e

From: Heejin Jang <[email-masked]>
Date: Wed, 30 Jan 2008 08:22:00 +0000 (GMT)

Hi, Jari.

The authors revised the draft based on the below comments and posted new one
(draft-ietf-mipshop-fh80216e-06.txt).
Kindly see the inline.

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Monday, January 21, 2008 2:06 AM
> To: [email-masked]
> Cc: [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Mip6] [Re] AD review of mipshop-fh80216e
> 
> Heejin,
> 
> >> I have done my AD review on this document. I have the 
> following comments:
> >>
> >> 1. The document needs to be clearer about when FMIP procedures are 
> >> needed upon link change, and when not. Section 5.2, for instance, 
> >> says "On receiving the LHI, the IP layer sends an FBU to the PAR." 
> >> But this appears to be necessary only if the FMIP operations (proxy 
> >> router solications) indicate that a router and subnet change is  implied by 
> >> the access point change. Same in Section 5.3.
> >>
> >>     
> >
> > Ok, I think that the unclearness results from omitting some 
> > descriptions about MN&#39;s past and current status in the FMIPv6 
> > procedures when the MN receives primitives. We&#39;ll clearly mention it 
> > during the next revision.
> >   
> 
> Ok, good.
> 

We clarified in Section 5.2 & 5.4 that the FMIPv6 operation is performed only when 
the MN moves to the network with the different subnet. The text is added as follows.

In Section 5.2     Handover Preparation

   Once the IP layer receives the LHI, it checks whether the specified
   target network belongs to the different subnet or not based on the
   information collected during Access Router Discovery step.  If the
   target proves to be in the same subnet, the MN can continue to use
   the current IP address after handover and there is no need to perform
   FMIPv6.  Otherwise, the IP layer formulates a prospective NCoA (New
   CoA) with the information provided in the PrRtAdv message and sends
   an FBU message to the PAR.

In Section 5.4    Handover Completion

   When the MN&#39;s IP layer receives the Link_Up primitive from the link
   layer, it should check whether it has moved into the target network
   predicted by FMIPv6.  In case the MN has moved to the same subnet,
   it does not perform the FMIPv6 operation.

> >> 2. The spec needs to document how it deals with the issues from RFC 
> >> 4907 Section 2.
> >>     
> >
> > Ok. We&#39;ll see RFC4907 and and describe in the draft how it 
> will deal those issues.
> >   
> 
> Ok.

We added some texts to reflect Section 5.2 of RFC4907.
We mainly considered the rate-limit problem and recovery 
from a invalid layer 2 indication. 

In Section 5.1    Access Router Discovery

   It is unlikely that RtSolPr messages may cause signaling overheads
   mentioned in Section 2 of [RFC4907].  The MN may detect more than one
   BSs and issue the Link_Detected primitives but not all at once.
   Furthermore, retransmission of RtSolPr messages are rate-limited by
   exponential backoff in [I-D.ietf-mipshop-fmipv6-rfc4068bis].

In Section 5.2.  Handover Preparation

   To avoid erroneous results due to unreliable and inconsistent
   characteristics of link, for instance, to move to the unpredicted
   network or to keep staying in the current network after sending an
   FBU, Section 2 of [RFC4907] advises to use combination of signal
   strength data with other techniques rather than relying only on
   signal strength for handover decision.  For example, an LHI may be
   sent after validating filtered signal strength measurements with
   other indications of link loss such as lack of beacon reception.

In Section 5.3.  Handover Execution

   Note that the Link_Up should not be sent due to changes in transient
   link conditions and less sensitive to link conditions as mentioned in
   Section 2 of [RFC4907].  However, the link may experience a
   intermittent loss.  Even in such a case, the following FMIPv6
   operation is performed only when the MN handovers to the link with
   different subnet and there is no signaling overhead as a result of a
   intermittent loss.

In Seciton 5.4.  Handover Completion

       o The MN may discover itself in the unpredicted network
         (erroneous movement). This is the case the MN moves to the
         network that is not the target specified in the LHI primitive.
         For the recovery from such a invalid indication which is
         mentioned in Section 2 of [RFC4907], the MN should send a new
         FBU to the PAR according to Section 5.6 of
         [I-D.ietf-mipshop-fmipv6-rfc4068bis] so that the PAR can update
         the existing binding entry and redirect the packets to the new
         confirmed location.

> >> 3. Has there been review in 802.16, 802.21, Wimax Forum, 
> or 16ng WGs?
> >>     
> >
> > As Vijay answered, the draft has been reviewed by 16ng experts and 
> > went through a Mipshop & 16ng joint WGLC. During 16ng 
> review, a 16ng 
> > chair made it reviewed by other SDO participants, IEEE 802.21 
> > (Yoshihiro Ohba), WiMax Forum (Jinhyeock Choi) (and also Netlmm WG 
> > (Jonne Soininen)) . We also consult a 802.21 secretary 
> (Xiaoyu Liu) to 
> > be sure of the use of proper MIH primitives.
> >   
> 
> All good.
> 
> > Do you think that the draft needs to be reviewed by SDOs 
> more before Last call?
> >   
> 
> No, not before Last Call.

Ok.

> >> 4. Can you confirm that 802.21 LD is given even for neighboring, 
> >> scanned links? I.e., even if you still are on your current 
> link, you 
> >> will an LD if another cell is heard nearby?
> >>     
> >
> > In my understanding, yes. Usually the wireless device such as WLAN 
> > card can detect the neighboring links though it still on 
> the current 
> > link if the neighboring links are using same wireless 
> technology. For 
> > e.g., in IETF meeting, we can see multiple APs except the AP used 
> > currently.
> >   
> 
> Ok. But I was not merely looking at what usually happens, the 
> question was specifically about the 802.16e link layer (or 
> 802.21 if it helps you here).
> Will it provide a Link Detected, even when you have NOT 
> changed to that link yet?
> 
> Text in Section 5.1, for instance, relies on this happening.
> 
> > I&#39;m not sure I got the point of this question .

The 802.16e provides a way to discover neighboring BSs while
an MN stays in the current network. 
In 802.16e, the serving BS broadcasts the information about the adjacent BSs 
by using the NA (Layer 2 Neighbor Advertisement). So, though the MN does not
change to that link, it can learn the existance of the neighboring BSs from the NA
and identify them through scanning. When the new BS is found through NA or 
scanningthe LD primitive is triggered to the IP layer.

> >   
> >> 5. What is "secure IP address management in 802.16e", mentioned in 
> >> the security considerations? I am surprised to hear of this, as no 
> >> mention of it has appeared in 16ng WG work.
> >>     
> >
> > "Particularly, the 802.16e architecture supports a number 
> of mandatory 
> > authentication mechanisms, for example, EAP-TTLS, EAP-SIM 
> and EAP-AKA, 
> > as well as, secure IP address management between the MN and its 
> > network entity." in the draft.
> >
> > This sentence means that 802.16e architecture (may) support the secure 
> > IP address management between MN & AR (ASN-GW) which is described in
> > 5.3 (security) of WiMAX release 1.1.2 document. However, 
> the sentence 
> > is not clear and confusable because secure IP address 
> management can 
> > be supported in WiMAX system not in 802.16e. We will revise it this 
> > sentence during the revision.
> >   
> 
> Ok. I&#39;m OK with having network access authentication such as TTLS etc.
> But they do not normally provide any form of secure IP 
> address management. There might be other functions (such as 
> source address spoofing prevention tied to L2) that do this, however.

We just deleted the ambiguous texts as follows. 

In Section 7.  Security Considerations

   The security consideration of the FMIPv6 specification
   [I-D.ietf-mipshop-fmipv6-rfc4068bis] is applicable to this document.
   Particularly, the 802.16e architecture supports a number of mandatory
   authentication mechanisms, for example, EAP-TTLS, EAP-SIM and EAP-AKA
   and that will allow secure handover operation of the MN.

> Waiting for the revised sentence.
> 
> Jari

Your feedback was very helpful to improve this document. 
Thanks for your kind consideration. 

- Best Regards, 
Heejin.
_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6