A Survey of Mobility Support in the Internet
draft-zhu-mobility-survey-04

[Ballot comment]
I support Stewart's DISCUSS.

I am wondering why was this document AD-sponsored and did not go on the Independent Stream. It obviously required quite a lot of efforts from the sponsoring AD (and the rest of the IESG) as there is a lot of information about more than a dozen of protocols whose accuracy needs to be verified. Then there will be some more as the document has obvious formatting and document structure issues. It is not clear to me what is the benefit.

Also, if we already are approving such a broad protocols survey I would have expected some informations about operational and manageability considerations. There is a discussion about deployment issues (which is good) but this is not sufficient.

[Ballot comment]
I support Stewart's DISCUSS.

I am wondering why was this document AD-sponsored and did not go on the Independent Stream. It obviously required quite a lot of efforts from the sponsoring AD (and the rest of the IESG) as there is a lot of information about more than a dozen of protocols whose accuracy needs to be verified. Then there will be some more as the document has obvious formatting and document structure issues. It is not clear to me what is the benefit.

Also, if we already are approving such a broader protocols survey I would have expected some informations about operational and manageability considerations. There is a discussion about deployment issues (which is good) but this is not sufficient.

[Ballot comment]
I support Stewart's DISCUSS.

I am wondering why was this document AD-sponsored and did not go on the Independent Stream. It obviously required quite a lot of efforts from the sponsoring AD (and the rest of the IESG) as there is a lot of information about more than a dozen of protocols whose accuracy needs to be verified. Then there will be some more as the document has obvious formatting and document structure issues. It is not clear to me what is the benefit.

Also, if we already are approving such a broader protocols survey I would have expected some informations about operational and manageability considerations.

[Ballot comment]
This is a fine document and I support its publication as an Informational RFC.

I have one nit: the use of "mobile" as a noun (e.g., "A system that keeps track each mobile's reachability during the mobile's moving") is colloquial and potentially confusing (e.g., in "mobile replies" is the term a noun or an adjective?). Because you do not want to distinguish between mobile nodes and mobile subnets, I suggest "mobile entity".

(There are also typographical errors, such as "Protocols like E2E, ILNP and BTMM fail into this design" instead of "fall into", but I assume that those will be fixed during the RFC Editor's review.)

[Ballot comment]
This is a fine document and I supports its publication as an Informational RFC.

I have one nit: the use of "mobile" as a noun (e.g., "A system that keeps track each mobile's reachability during the mobile's moving") is colloquial and potentially confusing (e.g., in "mobile replies" is the term a noun or an adjective?). Because you do not want to distinguish between mobile nodes and mobile subnets, I suggest "mobile entity".

(There are also typographical errors, such as "Protocols like E2E, ILNP and BTMM fail into this design" instead of "fall into", but I assume that those will be fixed during the RFC Editor's review.)

[Ballot comment]
This is a fine document and I supports its publication as an Informational RFC. I have one nit: the use of "mobile" as a noun (e.g., "A system that keeps track each mobile's reachability during the mobile's moving") is colloquial and potentially confusing (e.g., in "mobile replies" is the term a noun or an adjective?). Because you do not want to distinguish between mobile nodes and mobile subnets, I suggest "mobile entity".

[Ballot comment]
I can't check the reference so I can't figure out if there is any trade name issue with reference "Sony". Did the authors of the paper work for Sony?

[Ballot discuss]
ID-Nits says:

** The document seems to lack a Security Considerations section.

  ** The document seems to lack an IANA Considerations section.  (See Section
    2.2 of http://www.ietf.org/id-info/checklist for how to handle the case
    when there are no actions for IANA.)

  ** The document seems to lack separate sections for Informative/Normative
    References.  All references will be assumed normative when checking for
    downward references.

State changed to IESG Evaluation from Waiting for AD Go-Ahead.
AD Review: I was asked to AD sponsor this draft to an RFC. Sorry for the extremely long time this has taken to get to my review. But I have now reviewed it. Abstract from draft-zhu-mobility-survey:   Over the last two decades many efforts have been devoted to
  developing solutions for mobility support over the global Internet,
  which resulted in a variety of proposed solutions.  In this draft we
  conducted a systematic survey of the previous efforts to gain an
  overall understanding on the solution space of mobility support.
  This draft reports our finding and identifies remaining issues in
  providing ubiquitous and efficient global scale mobility support. The document is well written and a pleasure to read. It is a relevant overview of the mobility protocol design space, and its analysis is useful for thinking about the deployment issues that we've seen in this space. As far as I can tell, the document includes most of the relevant work (some exceptions noted below), and I have no major technical comments. I have sent the draft forward to IETF Last Call, and hope that you can work on the remaining issues during the last call, and get more suggestions and additional material from the last call reviewers. Technical: > 4.12. IKEv2 Mobility and Multihoming Protocol (MOBIKE)
>
>
>    MOBIKE is an extension to Internet Key Exchange (IKEv2) to support
>    mobility and multihoming.  The main purpose of MOBIKE is to allow
>    roaming devices to keep the existing IKE and IPsec SAs despite of IP
>    address changes.  The mobility support in MOBIKE allows both parties
>    to move, but it does not provide a rendezvous mechanism.  In other
>    words, simultaneous movement of both parties is not supported. Hmm. While this is true, part of the simultaneous mobility support is always in a stable anchor point, even in Mobile IP. If you assume mobike device 1 = host and mobike device 2 = gateway, then the situation really is equivalent to mobile IP mobile node - home agent arrangement. Home agent stays put, but mobiles can move around and everything still works. Also, I think it would be useful to state something about multihoming support in some of these protocols. Some do support this, for instance Mobike and more recently, also Mobile IP. A feature matrix for the different protocols is not so interesting, but it would be useful to understand what scope the different protocols have. > The reachability
>    information of the user's machine is published in DNS, and only
>    accessible to the subscriber.
>  "published in DNS" and "only accessible to the subscriber" do not appear to be compatible statements. Can you expand on this a bit? >    BTMM has millions of subscribers, which is perhaps the first large-
>    scale commercial host mobility support in Internet as of today. I wonder if the use of Mobile IP in CDMA/3GPP2 networks exceeds this. Please check. Also, since you are missing GTP which is essentially a non-IETF variant of PMIP, you should probably include GTP and note that that network-based mobility support is extremely widely used (to the order of a billion data users). > The second approach to mobility support is to provide a mapping
> between a mobile's stable identifier and its dynamically changing IP
> address.  Instead of notifying the world on every movement, a mobile
> only needs to update a single binding location about its location
> changes.  In this approach, if one level of indirection at IP layer
> is used, as in the case of Mobile IP, it has a potential side effect
> of introducing triangle routing; otherwise, if the two end nodes are
> aware of each other's movement, it means that both ends have to
> support the same mobility protocol.
>
> Yet there is the third case in which the protocols combine the above
> approaches, in the hope of keeping the pros and eliminating some cons
> of the two.  WINMO is a typically protocol in this case.
>  This is a very nice classification. But I have a question. How would you classify designs that include support for route optimization, such as Mobile IP? They do not impact routers, but still there's a need to update more than a single entity about a new location? Also, in Section 5.2 you talk about mobility aware entities, but this does not take into account whether the CNs are aware in route optimization mode. Missing: It might be valuable to describe the limited mobility support in transport layer solutions (SCTP and MP-TCP) as well. That is, they allow a single connection to stay up even as you move around, but do not by themselves allow simultaneous mobility of both parties. What about SHIM6? I would talk about GTP (a network-based mobility protocol) as well. What about mentioning application layer mobility designs (e.g., start from the paper by Henning on SIP mobility)? It might be useful to have at least some pointers to various optimization efforts that the community has spent quite a lot of time on. It felt that FMIP was the only one that was mentioned in addition to the general idea of route optimization in Mobile IP.  Look for pointers from the MIPSHOP WG's page, RFC 4651, etc. Editorial: > Xing, W., Karl, H., and A. Wolisz, "M-SCTP: Design and
> Prototypical Implementaion of An End-to-End Mobility
> Concept"
Typo >    LISP-Mobility [LISP-Mobility <http://tools.ietf.org/html/draft-zhu-mobility-survey-03#ref-LISP-Mobility>] is a relatively new design, in which
>    the designer hopes to utilize LISP[LISP], which is designed for
>    routing scalability, to support mobility as well. This sentence could probably be simplified a bit. Jari

IANA notes that this document does not contain a standard IANA
Considerations section. After examining the draft, IANA understands
that, upon approval of this document, there are no IANA Actions that
need completion.

[Note]: 'AD Review: I was asked to AD sponsor this draft to an RFC. Sorry for the extremely long time this has taken to get to my review. But I have now reviewed it. Abstract from draft-zhu-mobility-survey:   Over the last two decades many efforts have been devoted to
  developing solutions for mobility support over the global Internet,
  which resulted in a variety of proposed solutions.  In this draft we
  conducted a systematic survey of the previous efforts to gain an
  overall understanding on the solution space of mobility support.
  This draft reports our finding and identifies remaining issues in
  providing ubiquitous and efficient global scale mobility support. The document is well written and a pleasure to read. It is a relevant overview of the mobility protocol design space, and its analysis is useful for thinking about the deployment issues that we''ve seen in this space. As far as I can tell, the document includes most of the relevant work (some exceptions noted below), and I have no major technical comments. I have sent the draft forward to IETF Last Call, and hope that you can work on the remaining issues during the last call, and get more suggestions and additional material from the last call reviewers. Technical: > 4.12. IKEv2 Mobility and Multihoming Protocol (MOBIKE)
>
>
>    MOBIKE is an extension to Internet Key Exchange (IKEv2) to support
>    mobility and multihoming.  The main purpose of MOBIKE is to allow
>    roaming devices to keep the existing IKE and IPsec SAs despite of IP
>    address changes.  The mobility support in MOBIKE allows both parties
>    to move, but it does not provide a rendezvous mechanism.  In other
>    words, simultaneous movement of both parties is not supported. Hmm. While this is true, part of the simultaneous mobility support is always in a stable anchor point, even in Mobile IP. If you assume mobike device 1 = host and mobike device 2 = gateway, then the situation really is equivalent to mobile IP mobile node - home agent arrangement. Home agent stays put, but mobiles can move around and everything still works. Also, I think it would be useful to state something about multihoming support in some of these protocols. Some do support this, for instance Mobike and more recently, also Mobile IP. A feature matrix for the different protocols is not so interesting, but it would be useful to understand what scope the different protocols have. > The reachability
>    information of the user''s machine is published in DNS, and only
>    accessible to the subscriber.
>  "published in DNS" and "only accessible to the subscriber" do not appear to be compatible statements. Can you expand on this a bit? >    BTMM has millions of subscribers, which is perhaps the first large-
>    scale commercial host mobility support in Internet as of today. I wonder if the use of Mobile IP in CDMA/3GPP2 networks exceeds this. Please check. Also, since you are missing GTP which is essentially a non-IETF variant of PMIP, you should probably include GTP and note that that network-based mobility support is extremely widely used (to the order of a billion data users). > The second approach to mobility support is to provide a mapping
> between a mobile''s stable identifier and its dynamically changing IP
> address.  Instead of notifying the world on every movement, a mobile
> only needs to update a single binding location about its location
> changes.  In this approach, if one level of indirection at IP layer
> is used, as in the case of Mobile IP, it has a potential side effect
> of introducing triangle routing; otherwise, if the two end nodes are
> aware of each other''s movement, it means that both ends have to
> support the same mobility protocol.
>
> Yet there is the third case in which the protocols combine the above
> approaches, in the hope of keeping the pros and eliminating some cons
> of the two.  WINMO is a typically protocol in this case.
>  This is a very nice classification. But I have a question. How would you classify designs that include support for route optimization, such as Mobile IP? They do not impact routers, but still there''s a need to update more than a single entity about a new location? Also, in Section 5.2 you talk about mobility aware entities, but this does not take into account whether the CNs are aware in route optimization mode. Missing: It might be valuable to describe the limited mobility support in transport layer solutions (SCTP and MP-TCP) as well. That is, they allow a single connection to stay up even as you move around, but do not by themselves allow simultaneous mobility of both parties. What about SHIM6? I would talk about GTP (a network-based mobility protocol) as well. What about mentioning application layer mobility designs (e.g., start from the paper by Henning on SIP mobility)? It might be useful to have at least some pointers to various optimization efforts that the community has spent quite a lot of time on. It felt that FMIP was the only one that was mentioned in addition to the general idea of route optimization in Mobile IP.  Look for pointers from the MIPSHOP WG''s page, RFC 4651, etc. Editorial: > Xing, W., Karl, H., and A. Wolisz, "M-SCTP: Design and
> Prototypical Implementaion of An End-to-End Mobility
> Concept"
Typo >    LISP-Mobility [LISP-Mobility <http://tools.ietf.org/html/draft-zhu-mobility-survey-03#ref-LISP-Mobility>] is a relatively new design, in which
>    the designer hopes to utilize LISP[LISP], which is designed for
>    routing scalability, to support mobility as well. This sentence could probably be simplified a bit. Jari' added by Amanda Baber

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (A Survey of Mobility Support In the Internet) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'A Survey of Mobility Support In the Internet'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-03-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-zhu-mobility-survey/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-zhu-mobility-survey/

[Note]: 'AD Review:

I was asked to AD sponsor this draft to an RFC. Sorry for the extremely long time this has taken to get to my review. But I have now reviewed it.

Abstract from draft-zhu-mobility-survey:

  Over the last two decades many efforts have been devoted to
  developing solutions for mobility support over the global Internet,
  which resulted in a variety of proposed solutions.  In this draft we
  conducted a systematic survey of the previous efforts to gain an
  overall understanding on the solution space of mobility support.
  This draft reports our finding and identifies remaining issues in
  providing ubiquitous and efficient global scale mobility support.

The document is well written and a pleasure to read. It is a relevant overview of the mobility protocol design space, and its analysis is useful for thinking about the deployment issues that we've seen in this space. As far as I can tell, the document includes most of the relevant work (some exceptions noted below), and I have no major technical comments. I have sent the draft forward to IETF Last Call, and hope that you can work on the remaining issues during the last call, and get more suggestions and additional material from the last call reviewers.

Technical:

> 4.12. IKEv2 Mobility and Multihoming Protocol (MOBIKE)
>
>
>    MOBIKE is an extension to Internet Key Exchange (IKEv2) to support
>    mobility and multihoming.  The main purpose of MOBIKE is to allow
>    roaming devices to keep the existing IKE and IPsec SAs despite of IP
>    address changes.  The mobility support in MOBIKE allows both parties
>    to move, but it does not provide a rendezvous mechanism.  In other
>    words, simultaneous movement of both parties is not supported.

Hmm. While this is true, part of the simultaneous mobility support is always in a stable anchor point, even in Mobile IP. If you assume mobike device 1 = host and mobike device 2 = gateway, then the situation really is equivalent to mobile IP mobile node - home agent arrangement. Home agent stays put, but mobiles can move around and everything still works.

Also, I think it would be useful to state something about multihoming support in some of these protocols. Some do support this, for instance Mobike and more recently, also Mobile IP. A feature matrix for the different protocols is not so interesting, but it would be useful to understand what scope the different protocols have.

> The reachability
>    information of the user's machine is published in DNS, and only
>    accessible to the subscriber.
>  

"published in DNS" and "only accessible to the subscriber" do not appear to be compatible statements. Can you expand on this a bit?

>    BTMM has millions of subscribers, which is perhaps the first large-
>    scale commercial host mobility support in Internet as of today.

I wonder if the use of Mobile IP in CDMA/3GPP2 networks exceeds this. Please check. Also, since you are missing GTP which is essentially a non-IETF variant of PMIP, you should probably include GTP and note that that network-based mobility support is extremely widely used (to the order of a billion data users).

> The second approach to mobility support is to provide a mapping
> between a mobile's stable identifier and its dynamically changing IP
> address.  Instead of notifying the world on every movement, a mobile
> only needs to update a single binding location about its location
> changes.  In this approach, if one level of indirection at IP layer
> is used, as in the case of Mobile IP, it has a potential side effect
> of introducing triangle routing; otherwise, if the two end nodes are
> aware of each other's movement, it means that both ends have to
> support the same mobility protocol.
>
> Yet there is the third case in which the protocols combine the above
> approaches, in the hope of keeping the pros and eliminating some cons
> of the two.  WINMO is a typically protocol in this case.
>  

This is a very nice classification. But I have a question. How would you classify designs that include support for route optimization, such as Mobile IP? They do not impact routers, but still there's a need to update more than a single entity about a new location? Also, in Section 5.2 you talk about mobility aware entities, but this does not take into account whether the CNs are aware in route optimization mode.

Missing:

It might be valuable to describe the limited mobility support in transport layer solutions (SCTP and MP-TCP) as well. That is, they allow a single connection to stay up even as you move around, but do not by themselves allow simultaneous mobility of both parties. What about SHIM6?

I would talk about GTP (a network-based mobility protocol) as well.

What about mentioning application layer mobility designs (e.g., start from the paper by Henning on SIP mobility)?

It might be useful to have at least some pointers to various optimization efforts that the community has spent quite a lot of time on. It felt that FMIP was the only one that was mentioned in addition to the general idea of route optimization in Mobile IP.  Look for pointers from the MIPSHOP WG's page, RFC 4651, etc.

Editorial:

> Xing, W., Karl, H., and A. Wolisz, "M-SCTP: Design and
> Prototypical Implementaion of An End-to-End Mobility
> Concept"
Typo

>    LISP-Mobility [LISP-Mobility ] is a relatively new design, in which
>    the designer hopes to utilize LISP[LISP], which is designed for
>    routing scalability, to support mobility as well.

This sentence could probably be simplified a bit.

Jari

' added