Subject: [Mipshop] [Fwd: Re: Comments draft-ietf-mipshop-fh80216e-06]

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 26 Feb 2008 16:35:41 -0800

FYI.

I forwarded a bunch of comments that we got as a result of the
IETF last call on draft-ietf-mipshop-fh80216e-06. Heejin has
been addressing those comments and revising the draft. If anyone
has comments on the changes being made, now would be a good time
to speak up.

Vijay

Subject: Re: Comments draft-ietf-mipshop-fh80216e-06
From: "Reddy, Ranga Mr CIV USA USAMC" <[email-masked]>
To: "Reddy, Ranga Mr CIV USA USAMC" <[email-masked]>
Cc: [email-masked],[email-masked]
Date: Sun, 24 Feb 2008 20:38:22 -0500

Vijay,

I think I made a mistake with you email address earlier.  I had hoped to comment on the draft-ietf-mipshop-fh80216e-06 document.  I'm resending my initial email

ranga

----- Original Message -----
From: "Reddy, Ranga Mr CIV USA USAMC" <[email-masked]>
Date: Sunday, February 24, 2008 20:32
Subject: Comments draft-ietf-mipshop-fh80216e-06
To: [email-masked]]
Cc: [email-masked], [email-masked]

> Vijay,
> 
> Hi, I'm a member of the 802.16 working group.  DJ informed the 
> 802.16 working about the current draft you are working on.  I was 
> fairly busy this week and I apologize for not getting these 
> comments to you sooner.  I hope you can find them useful.
> 
> General Comments:
> -----------------
> 
> i) Basically, the intro of "FMIPv6 over 802.16e" is convoluted.
> ii) I'm not seeing any indication of MDHO or FBSS HO techniques.  
> Use of 
> these techniques in an 802.16 deployment would affect these drafts. 
> I'm not in the vendor or operator space (WiMAX forum), so I don't 
> know if MDHO/FBSS is being deployed along side "hard" HO.
> 
> 
> Specific Comments:
> ------------------
> A) Page 5, Paragraph 4:
> - The following sentence:
> "For the detailed procedure of the 802.16 network entry, refer
> to
> section 6.3.22 of [802.16e]."
> - Should read as:
> "For the detailed procedure of the 802.16 handover procedures,
> refer to
> section 6.3.22 of [802.16e]."
> 
> B) Starting Page 5/Paragraph 4 through top of Page 6:
>   "However, when the MN moves to a different subnet, it should
> re-configure a new  IP address and re-establish an IP  connection.  To
> resume the active session of the previous link, the MN should 
> perform IP
> 
> layer handover  additionally."
> - This statement asssumes a very specific network deployment, does it
> not?  Are you assuming a  single AR servicing multiple BSs?  Will 
> the AR then use the VLAN tagging to bridge multiple cells together? 
> What about a deployment where an AR is co-located with each BS?
> 
> C) Page 9/Paragraph 2:
>  "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."
> - Does the same subnet then imply one AR supports multiple cells?  Now
> while I do not disagree or have issue with this statement, how is
> forwarding to the MS in the new cell handled in this case?  Is it then
> enabled by some kind of tagging, and bridging function at the AR?
> 
> D) Page 9/Paragraph 4:
> - This whole paragraph, if MDHO is utilized as a HO technique, does
> FBU/FBack exchange have to happen before MOB_HO-IND tx by MS?  This 
> may be moot if MDHO/FBSS is not being deployed.
> 
> E) Page 10/Paragraph 4:
> - The following sentence:
> "In case the NAR has moved to the same subnet, the MN does not 
> perform the FMIPv6 operation."
> - Should read as:
> "In case the target (NAR) is within the the same subnet, the MN
> does
> not perform the FMIPv6 operation."
> to be consisant with with Page 9/Paragraph 2 and to be grammatically
> correct
> 
> F) Page 11:
> Is the statement(s) made in paragraph 4 contradictory to the ones made
> in paragraph 2.  4 assumes that the MN will get to use the NCoA it
> picked, but paragraph 2 states that this might not be the case.
> 
> 
> Appreciate the good work.
> 
> ranga
> 

Subject: RE: Comments draft-ietf-mipshop-fh80216e-06
From: Heejin Jang <[email-masked]>
To: Vijay Devarapalli <[email-masked]>, [email-masked]
Cc: Jari Arkko <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, [email-masked], [email-masked]
Date: Tue, 26 Feb 2008 07:44:03 +0000 (GMT)

Hi, Reddy.

I appreciate your valuable feedback.

Kindly see below for my reply.
I might not give right answers due to lack of my knowledge on 802.16e, 
then kindly let me know them.

I'll send the revised results soon in a separate mail.
 
> ----- Original Message -----
> From: "Reddy, Ranga Mr CIV USA USAMC" <[email-masked]>
> Date: Sunday, February 24, 2008 20:32
> Subject: Comments draft-ietf-mipshop-fh80216e-06
> To: [email-masked]]
> Cc: [email-masked], [email-masked]
> 
> > Vijay,
> > 
> > Hi, I'm a member of the 802.16 working group.  DJ informed the
> > 802.16 working about the current draft you are working on.  I was 
> > fairly busy this week and I apologize for not getting these 
> > comments to you sooner.  I hope you can find them useful.
> > 
> > General Comments:
> > -----------------
> > 
> > i) Basically, the intro of "FMIPv6 over 802.16e" is convoluted.

Ok. We'll polish the Section1 to make it more simple.

> > ii) I'm not seeing any indication of MDHO or FBSS HO techniques.  
> > Use of these techniques in an 802.16 deployment would affect these drafts. 
> > I'm not in the vendor or operator space (WiMAX forum), so I don't know 
> > if MDHO/FBSS is being deployed along side "hard" HO.

This document assumes a hard handover which is the default mode of 
802.16e handover, which will be clarified it in the introduction.

According to 802.16e spec, BSs belong to the same diversity set for MDHO/FBSS
are required to share all of the MN's MAC context. Specially, they should
send or should be able to send the same PDU for diversity, which seems that
they need to belong to the same AR (subnet) to receive the same PDU from the
AR. Consdering those things, in my understandiing, the BSs in the diversity set 
is likely to belong to the same subnet and no need of FMIPv6. I'd like to
check this but there seems no spec yet mentioning about the network deployment 
architecture of MDHO/FBSS in 802.16e nor WiMAX document. 

Furthermore, MDHO is a kind of soft handover, which allow MN to exchange 
the same (PDU) with multiple BSs, so there is no need of FMIPv6 when MN
moves between BSs (in the same set) involving in MDHO.

Therefore we think that it would be better to assume just hard handover in 
the draft. Any suggestion?

> > 
> > Specific Comments:
> > ------------------
> > A) Page 5, Paragraph 4:
> > - The following sentence:
> > "For the detailed procedure of the 802.16 network entry, refer to 
> > section 6.3.22 of [802.16e]."
> > - Should read as:
> > "For the detailed procedure of the 802.16 handover 
> procedures, refer 
> > to section 6.3.22 of [802.16e]."

Ok. 

> > B) Starting Page 5/Paragraph 4 through top of Page 6:
> >   "However, when the MN moves to a different subnet, it should 
> > re-configure a new  IP address and re-establish an IP  connection.  To 
> > resume the active session of the previous link, the MN should perform 
> > IP layer handover  additionally."
> > - This statement asssumes a very specific network deployment, does it 
> > not?  Are you assuming a  single AR servicing multiple BSs? Will the 
> > AR then use the VLAN tagging to bridge multiple cells together?
> > What about a deployment where an AR is co-located with each BS?

The statement is independent on whether AR is co-located with BS or not. 

When AR is co-located with BS, the subnet changes whenever MN moves to
another BS. When AR is not co-located with BS, the subnet changes 
only when MN moves another BS which belongs to the different AR.
In both cases, when the subnet changes, MN needs to configure IP address 
and perform IP layer handover for session continuity. 

> > C) Page 9/Paragraph 2:
> > "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."
> > - Does the same subnet then imply one AR supports multiple cells?  Now 
> > while I do not disagree or have issue with this statement, how is 
> > forwarding to the MS in the new cell handled in this case?  Is it then 
> > enabled by some kind of tagging, and bridging function at the AR?

The above text does not assume any 802.16e deployment/architecture.
One AR may support multiple cells or a single cell. In case of multiple cells, 
the AR may have the mapping info between CID and BSID, or using some
kinds of tagging as you mentioned. It can be implememted in a different way
in accordance with profile A, B, or C proposed in WiMAX, but this is not
in the scope of our document.

> > D) Page 9/Paragraph 4:
> > - This whole paragraph, if MDHO is utilized as a HO technique, does 
> > FBU/FBack exchange have to happen before MOB_HO-IND tx by MS?  This 
> > may be moot if MDHO/FBSS is not being deployed.

Answered previously.
 
> > E) Page 10/Paragraph 4:
> > - The following sentence:
> > "In case the NAR has moved to the same subnet, the MN does not perform 
> > the FMIPv6 operation."
> > - Should read as:
> > "In case the target (NAR) is within the the same subnet, the MN does 
> > not perform the FMIPv6 operation."
> > to be consisant with with Page 9/Paragraph 2 and to be grammatically 
> > correct

Ok.

> > F) Page 11:
> > Is the statement(s) made in paragraph 4 contradictory to the ones made 
> > in paragraph 2.  4 assumes that the MN will get to use the NCoA it 
> > picked, but paragraph 2 states that this might not be the case.

I think that this comment was for page 12, not 11. 
If so, I'll change the texts for clarity as below.

Old: 

   In both cases of predictive and reactive modes, the MN uses the NCoA
   as a source IP address of the UNA message and starts a DAD probe for
   NCoA concurrently according to [RFC4862].

New:

   In both cases of predictive and reactive modes, once it has moved into 
   the new link, it uses the NCoA formulated by the MN as a source address
   of the UNA, irrespective of validity check for the NCoA. It then starts a DAD
   probe for NCoA according to [RFC4862]. In case the NAR provides the MN 
   with a new NCoA, the MN MUST use the provided NCoA instead of the the 
   NCoA formulated by the MN.

> > 
> > Appreciate the good work.
> > 
> > ranga
> > 
> 

We think that your comment will be helpful to improve the document.
Thanks again. :)

- Best regards, 
Heejin.

Subject: Re: Comments draft-ietf-mipshop-fh80216e-06
From: "Reddy, Ranga Mr CIV USA USAMC" <[email-masked]>
To: [email-masked]
Cc: Vijay Devarapalli <[email-masked]>, Jari Arkko <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, [email-masked]
Date: Tue, 26 Feb 2008 10:25:41 -0500

Heejin,

I'm glad I could be of help.  Your observation about the MDHO seems to 
be very logical.  Since the implementation/deployment of MDHO or FBSS is 
in question, it is best to leave any mention of it out of your draft. 
If you or your colleagues, or DJ has any contacts in the forum I would 
suggest contacting them.  If the WiMAX forum makes a decision about it 
in the future, this draft may have to be revised at that point.

ranga

Heejin Jang wrote:
> Hi, Reddy.
> 
> I appreciate your valuable feedback.
> 
> Kindly see below for my reply.
> I might not give right answers due to lack of my knowledge on 802.16e, 
> then kindly let me know them.
> 
> I'll send the revised results soon in a separate mail.
>  
>> ----- Original Message -----
>> From: "Reddy, Ranga Mr CIV USA USAMC" <[email-masked]>
>> Date: Sunday, February 24, 2008 20:32
>> Subject: Comments draft-ietf-mipshop-fh80216e-06
>> To: [email-masked]]
>> Cc: [email-masked], [email-masked]
>>
>>> Vijay,
>>>
>>> Hi, I'm a member of the 802.16 working group.  DJ informed the
>>> 802.16 working about the current draft you are working on.  I was 
>>> fairly busy this week and I apologize for not getting these 
>>> comments to you sooner.  I hope you can find them useful.
>>>
>>> General Comments:
>>> -----------------
>>>
>>> i) Basically, the intro of "FMIPv6 over 802.16e" is convoluted.
> 
> Ok. We'll polish the Section1 to make it more simple.
> 
>>> ii) I'm not seeing any indication of MDHO or FBSS HO techniques.  
>>> Use of these techniques in an 802.16 deployment would affect these drafts. 
>>> I'm not in the vendor or operator space (WiMAX forum), so I don't know 
>>> if MDHO/FBSS is being deployed along side "hard" HO.
> 
> This document assumes a hard handover which is the default mode of 
> 802.16e handover, which will be clarified it in the introduction.
> 
> According to 802.16e spec, BSs belong to the same diversity set for MDHO/FBSS
> are required to share all of the MN's MAC context. Specially, they should
> send or should be able to send the same PDU for diversity, which seems that
> they need to belong to the same AR (subnet) to receive the same PDU from the
> AR. Consdering those things, in my understandiing, the BSs in the diversity set 
> is likely to belong to the same subnet and no need of FMIPv6. I'd like to
> check this but there seems no spec yet mentioning about the network deployment 
> architecture of MDHO/FBSS in 802.16e nor WiMAX document. 
> 
> Furthermore, MDHO is a kind of soft handover, which allow MN to exchange 
> the same (PDU) with multiple BSs, so there is no need of FMIPv6 when MN
> moves between BSs (in the same set) involving in MDHO.
> 
> Therefore we think that it would be better to assume just hard handover in 
> the draft. Any suggestion?
> 
>>> Specific Comments:
>>> ------------------
>>> A) Page 5, Paragraph 4:
>>> - The following sentence:
>>> "For the detailed procedure of the 802.16 network entry, refer to 
>>> section 6.3.22 of [802.16e]."
>>> - Should read as:
>>> "For the detailed procedure of the 802.16 handover 
>> procedures, refer 
>>> to section 6.3.22 of [802.16e]."
> 
> Ok. 
> 
>>> B) Starting Page 5/Paragraph 4 through top of Page 6:
>>>   "However, when the MN moves to a different subnet, it should 
>>> re-configure a new  IP address and re-establish an IP  connection.  To 
>>> resume the active session of the previous link, the MN should perform 
>>> IP layer handover  additionally."
>>> - This statement asssumes a very specific network deployment, does it 
>>> not?  Are you assuming a  single AR servicing multiple BSs? Will the 
>>> AR then use the VLAN tagging to bridge multiple cells together?
>>> What about a deployment where an AR is co-located with each BS?
> 
> The statement is independent on whether AR is co-located with BS or not. 
> 
> When AR is co-located with BS, the subnet changes whenever MN moves to
> another BS. When AR is not co-located with BS, the subnet changes 
> only when MN moves another BS which belongs to the different AR.
> In both cases, when the subnet changes, MN needs to configure IP address 
> and perform IP layer handover for session continuity. 
> 
>>> C) Page 9/Paragraph 2:
>>> "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."
>>> - Does the same subnet then imply one AR supports multiple cells?  Now 
>>> while I do not disagree or have issue with this statement, how is 
>>> forwarding to the MS in the new cell handled in this case?  Is it then 
>>> enabled by some kind of tagging, and bridging function at the AR?
> 
> The above text does not assume any 802.16e deployment/architecture.
> One AR may support multiple cells or a single cell. In case of multiple cells, 
> the AR may have the mapping info between CID and BSID, or using some
> kinds of tagging as you mentioned. It can be implememted in a different way
> in accordance with profile A, B, or C proposed in WiMAX, but this is not
> in the scope of our document.
> 
>>> D) Page 9/Paragraph 4:
>>> - This whole paragraph, if MDHO is utilized as a HO technique, does 
>>> FBU/FBack exchange have to happen before MOB_HO-IND tx by MS?  This 
>>> may be moot if MDHO/FBSS is not being deployed.
> 
> Answered previously.
>  
>>> E) Page 10/Paragraph 4:
>>> - The following sentence:
>>> "In case the NAR has moved to the same subnet, the MN does not perform 
>>> the FMIPv6 operation."
>>> - Should read as:
>>> "In case the target (NAR) is within the the same subnet, the MN does 
>>> not perform the FMIPv6 operation."
>>> to be consisant with with Page 9/Paragraph 2 and to be grammatically 
>>> correct
> 
> Ok.
> 
>>> F) Page 11:
>>> Is the statement(s) made in paragraph 4 contradictory to the ones made 
>>> in paragraph 2.  4 assumes that the MN will get to use the NCoA it 
>>> picked, but paragraph 2 states that this might not be the case.
> 
> I think that this comment was for page 12, not 11. 
> If so, I'll change the texts for clarity as below.
> 
> Old: 
> 
>    In both cases of predictive and reactive modes, the MN uses the NCoA
>    as a source IP address of the UNA message and starts a DAD probe for
>    NCoA concurrently according to [RFC4862].
> 
> New:
> 
>    In both cases of predictive and reactive modes, once it has moved into 
>    the new link, it uses the NCoA formulated by the MN as a source address
>    of the UNA, irrespective of validity check for the NCoA. It then starts a DAD
>    probe for NCoA according to [RFC4862]. In case the NAR provides the MN 
>    with a new NCoA, the MN MUST use the provided NCoA instead of the the 
>    NCoA formulated by the MN.
> 
>>> Appreciate the good work.
>>>
>>> ranga
>>>
> 
> We think that your comment will be helpful to improve the document.
> Thanks again. :)
> 
> - Best regards, 
> Heejin.
_______________________________________________
Mipshop mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mipshop

---

From: <[email-masked]>
Date: Tue, 26 Feb 2008 20:27:20 -0600

Hi Vijay, Heejin,

Regarding the removal of references to 802.21 due that being too SDO
specific, .21 is developed by the IEEE 802 LMSC just as .16e is. It is
the same SDO, so  the reference to .16e and .21 stand on equal footing. 

In Section 4, the MN is described as using native .16 L2 mechanisms for
network topology discovery. Although not specifically designed to
facilitate intra .16 handover, 802.21 also provides a service that can
provide the topology. The service (information service query)  is a MN
'pull', so is not subject to the particular DoS attack mentioned in
other reviews.

In Section 5, the adjective 'close'is used in reference to the use of
802.21, FMIPv6 and 802.16e. Since both 802.21 and FMIPv6 provide link
independent interfaces and services, this characterization can give the
wrong impression. In general MIP acceleration techniques and .21
services have at times been mis-labeled as 'close' when they achieve the
performance gains while providing standardized link independent
interfaces and services.

In Section 5.1, a review was concerned about the possibility of an
attacker triggering a flood of link detected events from the 802.21
implementation. This kind of attack will cause the MN to indicated some
kind of signal upward from the L2 implementation if the MN is listening
for these .16 messages. When .21 is being used, the link event is
'consumed' or 'interpreted' and presented upward in a media independent
fashion. It is possible (probably typical) for a .21 implementation to
have information that could help mitigate this attack. In suchi
mplementations, the MIHF would receive the link event from the .16e L2,
but deliver selected events upwards to FMIPv6.

In Section 5.2, the scenario does not include network initiated HO as a
possibility. Is it within the possible use cases to discuss such an
option?

Thanks for taking on this work. We really need these solutions to be
clear.

Best Regards,
Michael

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Vijay Devarapalli
>Sent: 26 February, 2008 16:36
>To: 'Mipshop'
>Subject: [Mipshop] [Fwd: Re: Comments draft-ietf-mipshop-fh80216e-06]
>
>FYI.
>
>been addressing those comments and revising the draft. If 
>anyone has comments on the changes being made, now would be a 
>good time to speak up.
>
>Vijay
>