Re: [Mipshop] WG last call on FMIPv6 for 3G CDMA networks

[Hidetoshi Yokota <yokota at kddilabs.jp>]

Hello Ashutosh-san,

I appreciate your valuable comments, which will be reflected in the 
document. Please see inline (one question):

Ashutosh Dutta wrote:
> Vijay, Yokota-san,
>                   Please find some overall general comments on this draft.
>
> Thanks
> Ashutosh
>
>
> Overall General Comments:
>
> - There are few 3G related terminologies that could be described early 
> on in the terminology section, (e.g., Pilot Sets, ANID, System ID, 
> Network ID, PZID)

Thanks. Terminology section should be more populated.

> - Section 5 briefly describes the applicability of predictive mode and 
> reactive mode for cellular networks. Providing little more details about 
> how mobility in cellular networks is different than WiFi networks may 
> help since there is already an RFC covering fast-handover in 802.11 (RFC 
> 4260) networks. It may also be a good idea to make a reference to RFC 
> 4260 (fast handover between WiFi networks)to create a motivation for 
> FMIPv6 for cellular networks (CDMA) and describe the difference.

The difference that should be addressed is that a 3G system uses 
specific identifiers/information for the mobile and the base station, 
which are different from something like MAC address. L2 attach procedure 
is quite a bit different, although it is not tightly coupled with FMIP 
operations. These difference should be more clarified.

> - In page 13, RFC 2472 could be cited when it says that MN should not 
> perform DAD in step “e”.

Since 3GPP2 also refers to RFC2472, this I-D should do it as well.

> - Step "f" in page 13 may need to restructured.

More explanation is needed? Could you elaborate on it a bit more, please?

> - Attachment procedure (g) in proactive case in figure 2 and attachment 
> procedure (e) in reactive case in figure 4 are probably same. The 
> document suggests that (g-3) to (g-9) are omitted during the initial 
> boot-strapping procedure. Does the same thing apply to attachment 
> procedure (e) in reactive scenario? Although step “e” in figure 4 is not 
> completely spelt out like procedure “g” in figure 3.

This is a valid comment and should be reflected in the document. One 
scenario that can be considered, however, is that in the reactive mode, 
the NCoA may not be obtained in the previous link, but in the new link. 
If this is the case, the RA will be needed to configure the NCoA in the 
new link. Otherwise, the above argument holds true.

> - Does Network Controlled Handover (Section 5.3) fall under proactive or 
> reactive? It appears to be proactive, but that should be spelt out somehow.

If the fast handover procedure takes full advantage of the assistance of 
the network, it should be the proactive mode. This should be spelt out.

> - Comment about step g (network attachment) in section 5.3 (figure 5) is 
> same as previous one

Yes.

> - In Section 5.3, step e, NAR MAY buffer (omit the extra s)

That's right.

> - Conclusions: The sentence - By introducing fast handover, not only are 
> more packets saved which otherwise …. Could be reworded.

Will review it...

Thanks a lot!
--
Hidetoshi

> Thanks
> Ashutosh
>
>
> Vijay Devarapalli wrote:
> > Hello,
> >
> > We have received no comments on this document. In fact there was no
> > one responding to the WG last call. We can't progress this document
> > to the IESG without explicit support.
> >
> > I am extending the WG last call to Oct 22nd. Please review the
> > document. If you have no comments and support advancing this document,
> > please send an email supporting advancing this document.
> >
> > Vijay
> >
> > Vijay Devarapalli wrote:
> > > Hello folks,
> > >
> > > This is to announce a working group last call for 
> > > draft-ietf-mipshop-3gfh-03.txt. You can find the document at the 
> > > following URL.
> > >
> > > http://www.ietf.org/internet-drafts/draft-ietf-mipshop-3gfh-03.txt
> > >
> > > The last call expires on October 3 2007.
> > >
> > > The intended status for this document is Informational.
> > >
> > > Please post any issues or comments on this document to the MIPSHOP WG 
> > > mailing list. In case you have reviewed the document and found no 
> > > issues, please send an email saying you support advancing this document.
> > >
> > > Vijay
> > >
> > > _______________________________________________
> > > Mipshop mailing list
> > > Mipshop at ietf.org
> > > https://www1.ietf.org/mailman/listinfo/mipshop
> >
> >
> >
> > _______________________________________________
> > Mipshop mailing list
> > Mipshop at ietf.org
> > https://www1.ietf.org/mailman/listinfo/mipshop
>
>
> _______________________________________________
> Mipshop mailing list
> Mipshop at ietf.org
> https://www1.ietf.org/mailman/listinfo/mipshop


_______________________________________________
Mipshop mailing list
Mipshop at ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop