Subject: [Mipshop] Protocol Action: 'IEEE 802.21 Mobility Services Framework Design (MSFD)' to Proposed Standard
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: mipshop mailing list <[email-masked]>, Internet Architecture Board <[email-masked]>, mipshop chair <[email-masked]>, RFC Editor <[email-masked]>
Date: Wed, 4 Feb 2009 07:34:27 -0800 (PST)
List-Id: <mipshop.ietf.org>

The IESG has approved the following document:

- 'IEEE 802.21 Mobility Services Framework Design (MSFD) '
   <draft-ietf-mipshop-mstp-solution-12.txt> as a Proposed Standard

This document is the product of the Mobility for IP: Performance, 
Signaling and Handoff Optimization Working Group. 

The IESG contact persons are Jari Arkko and Mark Townsley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mstp-solution-12.txt

Technical Summary

  This document describes a solution for discovering IEEE 802.21 
  Media Independent Handover (MIH) servers (called the MoS server) 
  and a transport layer mechanism for the reliable delivery of MIH 
  messages.

Working Group Summary

  This is an output from the MIPSHOP WG.

  The MIPSHOP WG received numerous liaison statements from the 
  IEEE 802.21 WG supporting this work. The solution described in 
  the document is supposed to provide a Layer 3 protocol for 
  transport of the handover assist information. The IEEE 802.21
  WG also provided the requirements for the solution.

Document Quality

   This specification has been reviewed by Jari Arkko for the IESG.

   There are no known implementations.

Personnel

   Document shepherd: Vijay Devarapalli
   Responsible AD: Jari Arkko

RFC Editor Note

  Please replace the first paragraph of Section 6.5 with this:

   The ES and CS messages are small in nature and have tight latency
   requirements. On the other hand, IS messages are more resilient in
   terms of latency constraints and some long IS messages could exceed
   the MTU of the path to the destination. TCP SHOULD be used as the
   default transport for all messages. However, UDP in combination
   with MIH acknowledgement SHOULD be used for transporting ES and CS
   messages that are shorter than or equal to the path MTU as
   described in Section 6.1.

IESG Note

  Please add the following IESG note to the document:

   As described later in this specification, this protocol does not
   provide security mechanisms. In some deployment
   situations lower layer security services may be sufficient.
   Other situations require proprietary mechanisms
   or as yet incomplete standard mechanisms, such as
   the ones currently considered by IEEE. For these reasons, the
   specification recommends careful analysis before considering any
   deployment.

   The IESG emphasizes the importance of these
   recommendations. The IESG also notes that this specification
   deviates from the traditional IETF requirement that support
   for security in the open Internet environment is a mandatory
   part of any Standards Track protocol specification. An exception
   has been made for this specification, but this should not be
   taken to mean that other future specifications are free from
   this requirement.

Content-class: urn:content-classes:message
Date: Mon, 9 Feb 2009 13:08:11 -0500
From: "Vijay Devarapalli" <[email-masked]>
To: <[email-masked]>
Subject: Re: [Mipshop] Protocol Action: 'IEEE 802.21 Mobility Services Framework Design (MSFD)' to Proposed Standard

Hello,

Good job to the design team that worked on this and all the folks who
were involved in this document later on.

Vijay=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of The IESG
> Sent: Wednesday, February 04, 2009 7:34 AM
> To: IETF-Announce
> Cc: mipshop mailing list; Internet Architecture Board;=20
> mipshop chair; RFC Editor
> Subject: [Mipshop] Protocol Action: 'IEEE 802.21 Mobility=20
> Services Framework Design (MSFD)' to Proposed Standard
>=20
> The IESG has approved the following document:
>=20
> - 'IEEE 802.21 Mobility Services Framework Design (MSFD) '
>    <draft-ietf-mipshop-mstp-solution-12.txt> as a Proposed Standard
>=20
> This document is the product of the Mobility for IP: Performance,=20
> Signaling and Handoff Optimization Working Group.=20
>=20
> The IESG contact persons are Jari Arkko and Mark Townsley.
>=20
> A URL of this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mstp-so
> lution-12.txt
>=20
> Technical Summary
>=20
>   This document describes a solution for discovering IEEE 802.21=20
>   Media Independent Handover (MIH) servers (called the MoS server)=20
>   and a transport layer mechanism for the reliable delivery of MIH=20
>   messages.
>=20
> Working Group Summary
>=20
>   This is an output from the MIPSHOP WG.
>=20
>   The MIPSHOP WG received numerous liaison statements from the=20
>   IEEE 802.21 WG supporting this work. The solution described in=20
>   the document is supposed to provide a Layer 3 protocol for=20
>   transport of the handover assist information. The IEEE 802.21
>   WG also provided the requirements for the solution.
>=20
> Document Quality
>=20
>    This specification has been reviewed by Jari Arkko for the IESG.
>=20
>    There are no known implementations.
>=20
> Personnel
>=20
>    Document shepherd: Vijay Devarapalli
>    Responsible AD: Jari Arkko
>=20
> RFC Editor Note
>=20
>   Please replace the first paragraph of Section 6.5 with this:
>=20
>    The ES and CS messages are small in nature and have tight latency
>    requirements. On the other hand, IS messages are more resilient in
>    terms of latency constraints and some long IS messages could exceed
>    the MTU of the path to the destination. TCP SHOULD be used as the
>    default transport for all messages. However, UDP in combination
>    with MIH acknowledgement SHOULD be used for transporting ES and CS
>    messages that are shorter than or equal to the path MTU as
>    described in Section 6.1.
>=20
>=20
> IESG Note
>=20
>   Please add the following IESG note to the document:
>=20
>    As described later in this specification, this protocol does not
>    provide security mechanisms. In some deployment
>    situations lower layer security services may be sufficient.
>    Other situations require proprietary mechanisms
>    or as yet incomplete standard mechanisms, such as
>    the ones currently considered by IEEE. For these reasons, the
>    specification recommends careful analysis before considering any
>    deployment.
>=20
>    The IESG emphasizes the importance of these
>    recommendations. The IESG also notes that this specification
>    deviates from the traditional IETF requirement that support
>    for security in the open Internet environment is a mandatory
>    part of any Standards Track protocol specification. An exception
>    has been made for this specification, but this should not be
>    taken to mean that other future specifications are free from
>    this requirement.
>=20
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mipshop
>=20

From: [email-masked]
To: [email-masked]
Date: Wed, 11 Feb 2009 10:00:01 -0800 (PST)
Cc: [email-masked]
Subject: [Mipshop] I-D Action:draft-ietf-mipshop-transient-bce-pmipv6-01.txt

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility for IP: Performance, Signaling and Handoff Optimization Working Group of the IETF.

	Title           : Transient Binding for Proxy Mobile IPv6
	Author(s)       : M. Liebsch, et al.
	Filename        : draft-ietf-mipshop-transient-bce-pmipv6-01.txt
	Pages           : 37
	Date            : 2009-02-11

This document specifies a mechanism which enhances Proxy Mobile IPv6
protocol signaling to support the creation of a transient binding
cache entry which is used for inter-MAG handover optimization.  This
mechanism is applicable to the mobile node's inter-MAG handover while
using a single interface or different interfaces.  The handover
problem space using the Proxy Mobile IPv6 base protocol is analyzed
and the use of transient binding cache entries at the local mobility
anchor is described.  The specified extension to the Proxy Mobile
IPv6 protocol ensures optimized forwarding of downlink as well as
uplink packets between mobile nodes and the network infrastructure
and avoids superfluous packet forwarding delay or even packet loss.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-transient-bce-pmipv6-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-mipshop-transient-bce-pmipv6-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Date: Thu, 12 Feb 2009 10:27:58 +0100 (CET)
From: Luca Valcarenghi <[email-masked]>
To: [email-masked]
Subject: [Mipshop] question about handover between ARs under different MAPs

Dear all,
I am new to the HMIPv6 field.
I have a (maybe trivial) question.
Could anybody tell me in which document I can find an answer, if any ?

Question:
Assume the following scenario: a Mobile Node (MN) moves from one 
Access Router (AR) AR1 in the subnet of Mobility Anchor Point (MAP) MAP1 to 
another AR2 in the MAP2 subnet. The two subnets are not overlapping. MN is 
registered to AR1-MAP1 then it registers to AR2-MAP2. How are the data 
forwarded to the MN while it moves ? Indeed, it seems to me that, before 
the MN sends a BU to the CN for replacing the 
Binding Cache (BC) HoA-RCoA1 with the BC HoA-RCoA2, data from the CN 
to the MN are still sent to MAP1. Are they forwarded to MAP2 somehow ?
Thanks a lot for the help.
Best regards,
 	Luca.

-- 
---
Luca Valcarenghi, Ph.D.
Scuola Superiore Sant'Anna
Center of Excellence for Information and Communications Engineering (CEIIC)
via G. Moruzzi 1, 56124, Pisa (PI), Italy
ph.: +39-0505492138
fax: +39-0505492194
web: www.ircphonet.it

From: [email-masked]
To: [email-masked]
Date: Sun, 15 Feb 2009 13:15:01 -0800 (PST)
Cc: [email-masked]
Subject: [Mipshop] I-D Action:draft-ietf-mipshop-rfc5268bis-00.txt

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility for IP: Performance, Signaling and Handoff Optimization Working Group of the IETF.

	Title           : Mobile IPv6 Fast Handovers
	Author(s)       : R. Koodli
	Filename        : draft-ietf-mipshop-rfc5268bis-00.txt
	Pages           : 50
	Date            : 2009-02-14

Mobile IPv6 enables a Mobile Node (MN) to maintain its connectivity
to the Internet when moving from one Access Router to another, a
process referred to as handover.  During handover, there is a period
during which the Mobile Node is unable to send or receive packets
because of link switching delay and IP protocol operations.  This
"handover latency" resulting from standard Mobile IPv6 procedures,
namely movement detection, new Care-of Address configuration, and
Binding Update, is often unacceptable to real-time traffic such as
Voice over IP (VoIP).  Reducing the handover latency could be
beneficial to non-real-time, throughput-sensitive applications as
well.  This document specifies a protocol to improve handover latency
due to Mobile IPv6 procedures.  This document does not address
improving the link switching latency.

This documents updates the packet formats for the Handover Initiate
(HI) and Handover Acknowledgement (HAck) messages to Mobility Header
Type.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-rfc5268bis-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-mipshop-rfc5268bis-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

From: [email-masked]
To: [email-masked]
Date: Wed, 18 Feb 2009 07:00:01 -0800 (PST)
Cc: [email-masked]
Subject: [Mipshop] I-D Action:draft-ietf-mipshop-pfmipv6-02.txt

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility for IP: Performance, Signaling and Handoff Optimization Working Group of the IETF.

	Title           : Fast Handovers for Proxy Mobile IPv6
	Author(s)       : H. Yokota, et al.
	Filename        : draft-ietf-mipshop-pfmipv6-02.txt
	Pages           : 29
	Date            : 2009-02-18

This document specifies the usage of Fast Mobile IPv6 (FMIPv6) when
Proxy Mobile IPv6 is used as the mobility management protocol.
Necessary extensions are specified for FMIPv6 to support the scenario
when the mobile node does not have IP mobility functionality and
hence is not involved with either MIPv6 or FMIPv6 operations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-pfmipv6-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-mipshop-pfmipv6-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Content-class: urn:content-classes:message
Date: Wed, 18 Feb 2009 20:06:29 -0500
From: "Vijay Devarapalli" <[email-masked]>
To: <[email-masked]>
Subject: [Mipshop] Revision of RFC 5268

Folks,

We are revising RFC 5268 to use mobility header based HI and HACK
messages instead of the existing ICMPv6 messages. This follows from
earlier discussions on using ICMPv6 vs  MH for HI and HACK messages in
draft-ietf-mipshop-pfmipv6-02.txt

Please review the changes.

Vijay

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of=20
> [email-masked]
> Sent: Sunday, February 15, 2009 1:15 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Mipshop] I-D Action:draft-ietf-mipshop-rfc5268bis-00.txt
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
> This draft is a work item of the Mobility for IP:=20
> Performance, Signaling and Handoff Optimization Working Group=20
> of the IETF.
>=20
>=20
> 	Title           : Mobile IPv6 Fast Handovers
> 	Author(s)       : R. Koodli
> 	Filename        : draft-ietf-mipshop-rfc5268bis-00.txt
> 	Pages           : 50
> 	Date            : 2009-02-14
>=20
> Mobile IPv6 enables a Mobile Node (MN) to maintain its connectivity
> to the Internet when moving from one Access Router to another, a
> process referred to as handover.  During handover, there is a period
> during which the Mobile Node is unable to send or receive packets
> because of link switching delay and IP protocol operations.  This
> "handover latency" resulting from standard Mobile IPv6 procedures,
> namely movement detection, new Care-of Address configuration, and
> Binding Update, is often unacceptable to real-time traffic such as
> Voice over IP (VoIP).  Reducing the handover latency could be
> beneficial to non-real-time, throughput-sensitive applications as
> well.  This document specifies a protocol to improve handover latency
> due to Mobile IPv6 procedures.  This document does not address
> improving the link switching latency.
>=20
> This documents updates the packet formats for the Handover Initiate
> (HI) and Handover Acknowledgement (HAck) messages to Mobility Header
> Type.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mipshop-rfc5268
> bis-00.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>=20

Date: Wed, 18 Feb 2009 18:21:12 -0800
From: Vijay Devarapalli <[email-masked]>
To: "Koodli, Rajeev" <[email-masked]>, [email-masked]
Subject: [Mipshop] Comments on draft-ietf-mipshop-rfc5268bis-00.txt

Hi Rajeev,

This document should obsolete RFC 5268. The first page says this 
document updates 5268.

In the Introduction, we might need some additional text on why we are 
modifying the format for HI and HACK messages. The paragraph that you 
added only mentions the following as justification.

    Specifying Mobility Header for the HI and HAck
    messages enables deployment of the protocol along-side PMIP6 and MIP6
    protocols.

You had used many more arguments while arguing for this change. :)

Unless we add additional text, we will always get questions on why we 
are revising message formats for a document that is already on the 
Standards Track.

>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> 
>                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                      |           Sequence #          |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |S|U|       Reserved            |    Reserved   |     Code      |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                                                               |
>      .                                                               .
>      .                          Mobility options                     .
>      .                                                               .
>      |                                                               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>                  Figure 6: Handover Initiate (HI) Message
> 
>          Sequence #: See [RFC3775].

Why not stick to the original term? In RFC 5268, we used "identifier" to 
match HI and HACK messages. We are calling it "Sequence number" here. 
There are two "Reserved" fields. One should be deleted.

How about the following for the HI message format?

                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |S|U|  Resvd    |     Code      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Identifier             |                               | 

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               .
      .                                                               .
      .                          Mobility options                     .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The same applies to the HACK message format too.

For the FBU message format, a lot more flags have been defined. 
http://www.iana.org/assignments/mobility-parameters lists the following.

> Registry Name: Binding Update Flags
> Reference: [RFC5213]
> Registration Procedures: Standards Action or IESG Approval
> 
> Registry:
> Flag  Value           Reference
> ----  --------------  ---------
> A     0x8000          [RFC3775]
> H     0x4000          [RFC3775]
> K     0x1000          [RFC3775]
> L     0x2000          [RFC3775]
> M     0x0800          [RFC4140]
> R     0x0400          [RFC3963]
> P     0x0200          [RFC5213]

You might want to mention that 'M', 'R', and 'P' are not relevant to FMIPv6.

Similarly for FBACK, you might want to mention that 'R' and 'P' are not 
relevant.

>       Length: The size of this option in octets iexcluding the Type, and
>       Length fields.

s/iexcluding/excluding

> 6.4.2.  Mobility Header IP Address/Prefix Option

I think we should call this "FMIPv6 IP Address/Prefix Option". Under 
mobility options we already have Mobile Network Prefix Option and Home 
Network Prefix Option, both of which can carry an address or prefix.

>    This document defines a new ICMPv6 message, which has been allocated
>    from the ICMPv6 Type registry.
> 
>       154 FMIPv6 Messages
> 
>    This document creates a new registry for the 'Subtype' field in the
>    above ICMPv6 message, called the "FMIPv6 Message Types".  IANA has
>    assigned the following values.
> 
>              +---------+-------------------+-----------------+
>              | Subtype |    Description    |    Reference    |
>              +---------+-------------------+-----------------+
>              |    2    |      RtSolPr      |  Section 6.1.1  |
>              |    3    |      PrRtAdv      |  Section 6.1.2  |
>              |    4    |  HI - Deprecated  | Section 6.2.1.1 |
>              |    5    | HAck - Deprecated | Section 6.2.1.2 |
>              +---------+-------------------+-----------------+
> 
>    The values '0' and '1' are reserved.  The upper limit is 255.  An RFC
>    is required for new message assignment.

You might want to add text that says '4' and '5' should be deprecated 
and marked as unassigned.

Vijay

Date: Thu, 19 Feb 2009 18:01:19 -0800
From: Vijay Devarapalli <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [Mipshop] Comments on draft-ietf-mipshop-pfmipv6-02.txt

Hello,

I reviewed the document. It still needs a fair amount of work before we 
can start a WG last call.

>    This document specifies the usage of Fast Mobile IPv6 (FMIPv6) when
>    Proxy Mobile IPv6 is used as the mobility management protocol.
>    Necessary extensions are specified for FMIPv6 to support the scenario
>    when the mobile node does not have IP mobility functionality and
>    hence is not involved with either MIPv6 or FMIPv6 operations.

Perhaps you should briefly mention what FMIPv6 does.

> 2.  Introduction
> 
>    Proxy Mobile IPv6 [RFC5213] provides IP mobility to a mobile node
>    that does not possess Mobile IPv6 [RFC3775] functionality.  

s/Mobile IPv6 [RFC3775] functionality/Mobile IPv6 [RFC3775] mobile node 
functionality/

> A proxy
>    agent in the network performs the mobility management signaling on
>    behalf of the mobile node.  This model transparently provides
>    mobility for Mobile Nodes within a PMIPv6 domain.  

You have used "mobile node" earlier in the paragraph.

> Nevertheless, the
>    basic performance of PMIPv6 in terms of handover latency and packet
>    loss is considered not any different from that of Mobile IPv6.
> 
>    Fast Handovers for Mobile IPv6 is specified in [RFC5268bis].  This
>    document applies the same Fast Handovers protocol for Proxy Mobile
>    IPv6 (PFMIPv6), in order to provide handover delay, packet loss and
>    transfer of network-resident contexts.  

You should use "minimize handover delay, reduce packet loss, etc...". It 
would be bad if the protocol provides handover delay and packet loss. :)

>    HO-Initiate:
>         A generic signaling that indicates the handover of the MN sent
>         from the P-AN to the PMAG.  While this signaling is dependent on
>         the access technology, it is assumed that HO-Initiate can carry
>         the information to identify the MN and to assist the PAR resolve
>         the NAR (e.g., the new access point or base station to which the
>         MN is moving).

Need to explicitly mention that this message is not being defined in 
this document.

> 
>                                   +----------+
>                                   |   LMA    |
>                                   |          |
>                                   +----------+
>                                     /      \
>                                    /        \
>                                   /          \
>                       +........../..+      +..\..........+
>                       . +-------+-+ .______. +-+-------+ .
>                       . |   PAR   |()_______)|   NAR   | .
>                       . |  (PMAG) | .      . |  (NMAG) | .
>                       . +----+----+ .      . +----+----+ .
>                       .      |      .      .      |      .
>                       .   ___|___   .      .   ___|___   .
>                       .  /       \  .      .  /       \  .
>                       . (  P-AN   ) .      . (  N-AN   ) .
>                       .  \_______/  .      .  \_______/  .
>                       .      |      .      .      |      .
>                       .   +----+    .      .   +----+    .
>                       .   | MN |  ---------->  | MN |    .
>                       .   +----+    .      .   +----+    .
>                       +.............+      +.............+
> 
>                Figure 1: Reference network for fast handover

You have to mention somewhere that "P-AN" and "N-AN" refer to the radio 
elements of the access network. The PAR and the NAR are the first hop 
routers for the mobile node. So when you say there is a network between 
the MN and the PAR/NAR, it is confusing.

>                                             PMAG        NMAG
>           MN         P-AN       N-AN        (PAR)       (NAR)     LMA
>           |           |          |            |           |        |
>           |  Report   |          |            |           |        |
>      (a)  |-(MN ID,-->|          |            |           |        |
>           | New AP ID)|          |            |           |        |
>           |           |     HO Initiate       |           |        |
>      (b)  |           |--(MN ID, New AP ID)-->|           |        |
>           |           |          |            |           |        |
>           |           |          |            |    HI     |        |
>      (c)  |           |          |            |-(MN ID, ->|        |
>           |           |          |            | MN IID, LMAA)      |
>           |           |          |            |           |        |
>      (d)  |           |          |            |<---HAck---|        |
>           |           |          |            |  (MN ID)  |        |
>           |           |          |            |           |        |
>           |           |          |            |HI/HAck(optional)   |
>      (e)  |           |          |            |<- - - - ->|        |

What is this HI/HACK for? Later in the text you say

    (e)  The NAR may optionally request the PAR to buffer or forward
         packets by setting U or F flags in the HI message, respectively.

Is this exchange just for indicating the two flags, 'U' and 'F'? Is 
there anything else sent in this HI/HACK exchange?

         This step may be combined with steps (c) and (d).

How? In step (c), the HI goes from PAR to NAR. In step (e), the HI goes 
from NAR to PAR. How can you combine the two? Or did you mean, the NAR 
can send a HI as soon as it receives a HI from the PAR before responding 
with a HACK? It is confusing.

>      (f)  |           |          |            |==DL data=>|        |

Don't you have to show the "DL data" from the LMA to the PAR before 
showing the "DL data" from the PAR to the NAR?

>           |           |          |            |           |        |
>      (g) ~~~          |          |            |           |        |
>          ~~~          |          |            |           |        |
>           |   MN-AN connection   |    AN-MAG connection   |        |
>      (h)  |<---establishment---->|<----establishment----->|        |
>           |           |          |  (substitute for UNA)  |        |
>           |           |          |            |           |        |
>      (i)  |<==================DL data=====================|        |
>           |           |          |            |           |        |
>      (j)  |===================UL data====================>|#       |
>           |           |          |           #|<==========|#       |
>           |           |          |           #|===================>|
>           |           |          |            |HI/HAck(optional)   |
>      (k)  |           |          |            |<- - - - ->|        |

I did not understand the purpose of this HI/HACK at all.

>    (b)  The previous access network (P-AN), to which the MN is currently
>         attached, indicates the handover of the MN to the PAR (PMAG).

Again, mention that this message is out of scope.

>    (k)  The PAR MAY send the HI message to indicate that the packet
>         forwarding is completed.

When does the PAR send this message? The PAR has no idea that the 
binding cache entry at the LMA has been updated with the NAR's address 
and therefore no more traffic meant for the MN will come to the PAR. I 
suggest removing this.

>    If the network that the MN has moved to does not support PMIPv6 but
>    only MIPv6 (i.e. there exists a MIPv6 HA) and the MN supports MIPv6
>    at the same time, the MN and HA can exchange BU/BA instead of PBU/PBA
>    in steps (j) and (k).  If this is the case, the LMA and HA will most
>    likely be collocated and the LMA (HA) address should be maintained in
>    the new network for communication continuity.  Since the LMA (HA)
>    address is transferred to the NAR in step (c), the MN can retrieve it
>    at or after step (g) by e.g. the authentication or DHCP procedure
>    (not shown in the figure).

Perhaps this paragraph should be moved to an appendix that explains what 
happens when the mobile node moves out of a PMIPv6 domain. It is 
distracting in the current position.

>    (g)  The PAR MAY send the HI message to indicate that the packet
>         forwarding is completed.

Same issue as before. How does the PAR figure out when to send the HI 
message?

>    Also, in step (c), the NAR could send an unsolicited HAck message to
>    the PAR, which then triggers the HI message from the PAR.  By doing
>    so, the directions of HI/HAck messages are aligned with the
>    predictive (PAR-initiated) fast handover.  Further study is needed if
>    this call flow is more appropriate than the current one.

Why have two mechanisms for the same? The NAR could just send a HI and 
get the response in a HACK message. Why bother sending an unsolicited 
HACK message? And what do you mean by "Further Study"? Are you saying we 
don't enough to say whether the NAR should send a HI message or an 
unsolicited HACK message for a reactive handover? So both options are 
allowed. (?)

> 6.1.1.  Handover Initiate (HI)
> 
>    This section defines extensions to the HI message in [RFC5268bis].
>    The format of the Message Data field in the Mobility Header is as
>    follows:
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>                                      +---------------+-+-+-----------+
>                                      |           Sequence #          |
>      +-+-+-+-------------------------+---------------+-+-+-----------+
>      |S|U|F|                 Reserved                |     Code      |
>      +-+-+-+-----------------------------------------+---------------+
>      |                                                               |
>      .                                                               .
>      .                       Mobility options                        .
>      .                                                               .
>      |                                                               |
>      +---------------------------------------------------------------+
> 
>    IP Fields:
> 
>    Source Address
> 
>                        The IP address of PMAG or NMAG
> 
>    Destination Address
> 
>                        The IP address of the peer MAG
> 
>    Message Data:
> 
>    Sequence #  Same as [RFC5268bis].
> 
>    S flag      Must be set to zero (defined in [RFC5268bis]).
> 
>    U flag      Buffer flag.  Same as [RFC5268bis].
> 
>    F flag      Forwarding flag.  Used to request to forward the packets
>                for the MN.

You should describe the 'F' flag here and refer to 5268bis for all other 
  fields.

>    Code        If F flag is not set, the Code MUST be set to zero.
>                Otherwise, the Code value has the following meaning:
> 
>                          0: Reserved
> 
>                          1: Forwarding is not requested
> 
>                          2: Request forwarding
> 
>                          3: Indicate the completion of forwarding

There is an issue here. 5268bis already has semantics for code set to 
'0' and '1'. I think you should start at '2' in this document.

> 6.1.2.  Handover Acknowledge (HAck)
> 
>    This section defines extensions to the HAck message in [RFC5268bis].
>    The format of the Message Data field in the Mobility Header is as
>    follows:
> 
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>                                      +---------------+---------------+
>                                      |           Sequence #          |
>      +-------------------------------+---------------+---------------+
>      |                       Reserved                |     Code      |
>      +-----------------------------------------------+---------------+
>      |                                                               |
>      .                                                               .
>      .                       Mobility options                        .
>      .                                                               .
>      |                                                               |
>      +---------------------------------------------------------------+

Since this document is not making any change to the HACK message format, 
do you need to show the message here? Perhaps you can just refer to 5268bis.

>                        5: Context Transferred successfully, more context
>                        available

What does this mean? Is it saying there will be more unsolicited HACK 
messages that follow with more context? If so, how are they all 
correlated at the NAR? If not, does it mean the NAR has to send more HI 
messages to get more context from the PAR?

> 6.2.  Mobility Options
> 
> 6.2.1.  Context Request Option
> 
>    This option is sent in the HI message to request context information
>    on the MN.
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +---------------+---------------+---------------+---------------+
>      |  Option-Type  | Option-Length |           Reserved            |
>      +---------------+---------------+-------------------------------+
>      |  Req-type-1   | Req-length-1  |  Req-type-2   | Req-length-2  |
>      +---------------------------------------------------------------+
>      |                              ...                              |

What does the above format mean? Where is the data in each request? Is 
it just request type and request length? Does Req-type use the same name 
space as mobility options? If so, this creates a problem. Mobility 
options are supposed to be carried in a mobility header message. Here 
you carrying the mobility options in another mobility option (Context 
Request Option).

If you are not using the same name space as mobility options, are you 
creating a new name space for the "Req-type" field?

>    Context Request Option is typically used for the reactive (NAR-

How come there is no "Context Response option" defined?

>    In the case where there are only Req-type-n and Req-length-n fields,
>    the value of the Req-length-n is set to zero.  If additional
>    information besides the Req-type-n is necessary to uniquely specify
>    the requested context, such information follows after the
>    Req-length-n.  For example, when the requested context is the Vendor-
>    Specific Option defined in Section 6.2.8, the requested option format
>    looks as follows:
> 
>      |                              ...                              |
>      +---------------+---------------+-------------------------------+
>      | Req-type-N=19 | Req-length-N=6|           Vendor-ID           |
>      +-------------------------------+-------------------------------+
>      |           Vendor-ID           |           Sub-Type            |
>      +---------------------------------------------------------------+
>      |                              ...                              |

I don't think a Vendor Specific Mobility Option can be a sub-option of 
the Context Request Mobility Option.

> 6.2.2.  Local Mobility Anchor Address (LMAA) Option
> 
>    This option is used to transfer the Local Mobility Anchor Address
>    (LMAA), with which the MN is currently registered.  The detailed
>    definition of the LMAA is described in [RFC5213].
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |  Option-Type  | Option-Length |          Reserved             |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                                                               |
>      +                                                               +
>      |                                                               |
>      +                 Local Mobility Anchor Address                 +
>      |                                                               |
>      +                                                               +
>      |                                                               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Why don't you add a field here that indicates whether you are carrying 
the IPv4 address or the IPv6 address of the LMA? I don't like the fact 
that you have a LMA address option for carrying the IPv6 address of the 
LMA, and another IPv4 address option that can carry either the IPv4 
address of the LMA or the mobile node.

> 6.2.4.  Home Network Prefix Option
> 
>    This option is used to transfer the home network prefix that is
>    assigned to the MN in the P-AN.  The format of this option follows
>    the Home Network Prefix Option defined in [RFC5213].

Re-word the last sentence to

   The Home Network Prefix Option defined in [RFC5213] is used for this.

> 6.2.5.  Mobile Node Interface Identifier (MN IID) Option
> 
>    This option is used to transfer the interface identifier of the MN
>    that is used in the P-AN.  The format of this option follows the
>    Mobile Node Interface Identifier Option defined in [RFC5213].

Re-word the last sentence as

   The Mobile Node Interface Identifier Option defined in [RFC5213] is
   used for this.

> 6.2.6.  Link-local Address Option
> 
>    This option is used to transfer the link-local address of the PAR
>    (PMAG).  The format of this option follows the Link-local Address
>    Option defined in [RFC5213].

Same as above.

> 7.  Security Considerations
> 
>    Security issues for this document follow those for PMIPv6[RFC5213]
>    and FMIPv6[RFC5268bis].  In PMIPv6, MAG and LMA are assumed to share
>    security association.  In FMIPv6, the access routers (i.e., the PMAG
>    and NMAG in this document) are assumed to share security association.
>    No new security risks are identified.  Support for integrity
>    protection using IPsec is required, but support for confidentiality
>    is not necessary.

I think you need support for confidentiality protection if there is some 
sensitive MN context is being transfered. You should say 
"Confidentiality protection SHOULD be used if sensitive context related 
to the mobile node is being transferred".

> 8.  IANA Considerations
> 
>    This document defines two new mobility options, which are described
>    in Section 6.2.  The Type value for these options are assigned from
>    the same numbering space as allocated for the other mobility options,
>    as defined in [RFC3775].
> 
>     Mobility Options
>     Value  Description                            Reference
>     -----  -------------------------------------  -------------
>     TBD1   Context Request Option                 Section 6.2.1
>     TBD2   Local Nobility Anchor Address Option   Section 6.2.2
>     TBD3   IPv4 Address Option                    Section 6.2.3

This would need revision if we conclude that existing mobility options 
cannot become sub-options of the Context Request mobility option.

Vijay

Content-class: urn:content-classes:message
Date: Fri, 20 Feb 2009 17:40:32 -0500
From: "Koodli, Rajeev" <[email-masked]>
To: <[email-masked]>
Subject: Re: [Mipshop] Comments on draft-ietf-mipshop-rfc5268bis-00.txt

=20

Hi Vijay,

Thanks for the review.

> This document should obsolete RFC 5268. The first page says=20
> this document updates 5268.

Okay.

>=20
> In the Introduction, we might need some additional text on=20
> why we are modifying the format for HI and HACK messages. The=20
> paragraph that you added only mentions the following as justification.
>=20
>     Specifying Mobility Header for the HI and HAck
>     messages enables deployment of the protocol along-side=20
> PMIP6 and MIP6
>     protocols.
>=20
> You had used many more arguments while arguing for this change. :)
>=20

They are all in the proceedings of the last IETF. They all lead to the
above conclusion: how best to enable the deployment of IP Mobility
protocols.=20

> Unless we add additional text, we will always get questions=20
> on why we are revising message formats for a document that is=20
> already on the Standards Track.

The WG already discussed this and agreed for this. You mean in reviews
later on?
We can address them I think.

>=20
> >       0                   1                   2                   3
> >       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6=20
> 7 8 9 0 1
> >=20
> >                                     =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >                                      |           Sequence #=20
>          |
> >     =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |S|U|       Reserved            |    Reserved   |    =20
> Code      |
> >     =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |                                                     =20
>          |
> >      .                                                     =20
>          .
> >      .                          Mobility options           =20
>          .
> >      .                                                     =20
>          .
> >      |                                                     =20
>          |
> >     =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >=20
> >                  Figure 6: Handover Initiate (HI) Message
> >=20
> >          Sequence #: See [RFC3775].
>=20
> Why not stick to the original term? In RFC 5268, we used=20
> "identifier" to match HI and HACK messages. We are calling it=20
> "Sequence number" here.=20

I thought about it.. I think it is better to go with Sequence Number
because all the MH messages (FBU, Fback, HI, Hack) can have the
consistency, and the purpose is the same. What do you think?

> There are two "Reserved" fields. One should be deleted.
>=20
> How about the following for the HI message format?
>=20
>                                      =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                       |S|U|  Resvd    |    =20
> Code      |
>      =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |        Identifier             |                      =20
>         |=20
>=20
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                      =20
>         .
>       .                                                      =20
>         .
>       .                          Mobility options            =20
>         .
>       .                                                      =20
>         .
>       |                                                      =20
>         |
>      =20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20

I wanted to follow the same format as the FBU (as I mentioned above).
So, you would Sequence Number followed by flags and the first Reserved
field. Byte 3 in HI and Hack is also Reserved because Code is a single
byte field. Any suggestions on keeping the MH messages consistent?=20

> The same applies to the HACK message format too.
>=20
> For the FBU message format, a lot more flags have been defined.=20
> http://www.iana.org/assignments/mobility-parameters lists the=20
> following.
>=20
> > Registry Name: Binding Update Flags
> > Reference: [RFC5213]
> > Registration Procedures: Standards Action or IESG Approval
> >=20
> > Registry:
> > Flag  Value           Reference
> > ----  --------------  ---------
> > A     0x8000          [RFC3775]
> > H     0x4000          [RFC3775]
> > K     0x1000          [RFC3775]
> > L     0x2000          [RFC3775]
> > M     0x0800          [RFC4140]
> > R     0x0400          [RFC3963]
> > P     0x0200          [RFC5213]
>=20
> You might want to mention that 'M', 'R', and 'P' are not=20
> relevant to FMIPv6.
>=20

Okay.

> Similarly for FBACK, you might want to mention that 'R' and=20
> 'P' are not relevant.
>=20

Ok.

> >       Length: The size of this option in octets iexcluding=20
> the Type, and
> >       Length fields.
>=20
> s/iexcluding/excluding
>=20

Good.

> > 6.4.2.  Mobility Header IP Address/Prefix Option
>=20
> I think we should call this "FMIPv6 IP Address/Prefix=20
> Option". Under mobility options we already have Mobile=20
> Network Prefix Option and Home Network Prefix Option, both of=20
> which can carry an address or prefix.
>=20

Okay. (I was going with the semantics of MH-LLA title)

> >    This document defines a new ICMPv6 message, which has=20
> been allocated
> >    from the ICMPv6 Type registry.
> >=20
> >       154 FMIPv6 Messages
> >=20
> >    This document creates a new registry for the 'Subtype'=20
> field in the
> >    above ICMPv6 message, called the "FMIPv6 Message Types".=20
>  IANA has
> >    assigned the following values.
> >=20
> >              +---------+-------------------+-----------------+
> >              | Subtype |    Description    |    Reference    |
> >              +---------+-------------------+-----------------+
> >              |    2    |      RtSolPr      |  Section 6.1.1  |
> >              |    3    |      PrRtAdv      |  Section 6.1.2  |
> >              |    4    |  HI - Deprecated  | Section 6.2.1.1 |
> >              |    5    | HAck - Deprecated | Section 6.2.1.2 |
> >              +---------+-------------------+-----------------+
> >=20
> >    The values '0' and '1' are reserved.  The upper limit is=20
> 255.  An RFC
> >    is required for new message assignment.
>=20
> You might want to add text that says '4' and '5' should be=20
> deprecated and marked as unassigned.

I see, ok.

Regards,

-Rajeev

>=20
> Vijay
>=20
>=20
>=20

Date: Mon, 23 Feb 2009 16:42:33 -0800
From: Vijay Devarapalli <[email-masked]>
To: "Koodli, Rajeev" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Mipshop] Comments on draft-ietf-mipshop-rfc5268bis-00.txt

Koodli, Rajeev wrote:
>  
> 
> Hi Vijay,
> 
> Thanks for the review.
> 
>> This document should obsolete RFC 5268. The first page says 
>> this document updates 5268.
> 
> Okay.
> 
>> In the Introduction, we might need some additional text on 
>> why we are modifying the format for HI and HACK messages. The 
>> paragraph that you added only mentions the following as justification.
>>
>>     Specifying Mobility Header for the HI and HAck
>>     messages enables deployment of the protocol along-side 
>> PMIP6 and MIP6
>>     protocols.
>>
>> You had used many more arguments while arguing for this change. :)
>>
> 
> They are all in the proceedings of the last IETF. They all lead to the
> above conclusion: how best to enable the deployment of IP Mobility
> protocols. 
> 
>> Unless we add additional text, we will always get questions 
>> on why we are revising message formats for a document that is 
>> already on the Standards Track.
> 
> The WG already discussed this and agreed for this. You mean in reviews
> later on?
> We can address them I think.

One option is to respond to each reviewer (later in the IETF last call
and IESG review) on why we are modifying the HI and HACK messages to use
the mobility header. The other option is to mention a few reasons in the
draft itself. I prefer the latter.

>>>          Sequence #: See [RFC3775].
>> Why not stick to the original term? In RFC 5268, we used 
>> "identifier" to match HI and HACK messages. We are calling it 
>> "Sequence number" here. 
> 
> I thought about it.. I think it is better to go with Sequence Number
> because all the MH messages (FBU, Fback, HI, Hack) can have the
> consistency, and the purpose is the same. What do you think?

hmm.. What do we gain out of keeping the HI message format similar to 
FBU's format? If there is no significant gain, I would prefer keeping 
the format similar to the HI message in RFC 5268. We can't obviously 
re-use data structures. For example, the flags in HI and flags in FBU 
would overlap. That would be a problem.

>> There are two "Reserved" fields. One should be deleted.
>>
>> How about the following for the HI message format?
>>
>>                                       
> I wanted to follow the same format as the FBU (as I mentioned above).
> So, you would Sequence Number followed by flags and the first Reserved
> field. Byte 3 in HI and Hack is also Reserved because Code is a single
> byte field. Any suggestions on keeping the MH messages consistent? 

I want to understand why the MH messages have to be consistent. We after 
all have 12 messages already defined (with three more on the way). They 
all have very different message formats. The only exception is BU and FBU.

Vijay

Content-class: urn:content-classes:message
Date: Mon, 23 Feb 2009 20:07:12 -0500
From: "Koodli, Rajeev" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Mipshop] Comments on draft-ietf-mipshop-rfc5268bis-00.txt

=20

> One option is to respond to each reviewer (later in the IETF=20
> last call and IESG review) on why we are modifying the HI and=20
> HACK messages to use the mobility header. The other option is=20
> to mention a few reasons in the draft itself. I prefer the latter.

Ok, let me think about it..

> hmm.. What do we gain out of keeping the HI message format=20
> similar to FBU's format? If there is no significant gain, I=20
> would prefer keeping the format similar to the HI message in=20
> RFC 5268. We can't obviously re-use data structures. For=20
> example, the flags in HI and flags in FBU would overlap. That=20
> would be a problem.

No, we cannot re-use data structures, but all the MH messages would have
a consistent format.

Put anothr way, what do we gain by keeping the ICMP header fields?

The purpose of the Sequence Number field is the same in FBU and HI, but
we would end up having two different fields (Sequence Number,
Identifier) for the purpose.

I would like to avoid having different fields for the same purpose when
using the same message header type (i.e., MH).

>=20
> I want to understand why the MH messages have to be=20
> consistent. We after all have 12 messages already defined=20
> (with three more on the way). They all have very different=20
> message formats. The only exception is BU and FBU.

They don't have to be the same across protocol specifications. Within a
same protocol, it would be good to have the consistent format. See the
comment above regarding using Seq # vs. Identifier.

Thanks,

-Rajeev

>=20
> Vijay
>=20
>=20

Content-class: urn:content-classes:message
Date: Tue, 24 Feb 2009 20:08:29 -0500
From: "Vijay Devarapalli" <[email-masked]>
To: <[email-masked]>
Subject: Re: [Mipshop] Comments on draft-ietf-mipshop-rfc5268bis-00.txt

Hello,

We had a discussion offline and concluded on the following for the HI
message format.

                                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 |        Sequence Number        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |S|U|  Resvd    |     Code      |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               .
 .                                                               .
 .                          Mobility options                     .
 .                                                               .
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20

The 'Sequence Number' will be similar to the 'Identifier' field in RFC
5268.

Vijay

> -----Original Message-----
> From: Koodli, Rajeev [mailto:[email-masked]]=20
> Sent: Monday, February 23, 2009 5:07 PM
> To: Vijay Devarapalli
> Cc: [email-masked]
> Subject: RE: [Mipshop] Comments on=20
> draft-ietf-mipshop-rfc5268bis-00.txt
>=20
> =20
>=20
> > One option is to respond to each reviewer (later in the IETF=20
> > last call and IESG review) on why we are modifying the HI and=20
> > HACK messages to use the mobility header. The other option is=20
> > to mention a few reasons in the draft itself. I prefer the latter.
>=20
> Ok, let me think about it..
>=20
> > hmm.. What do we gain out of keeping the HI message format=20
> > similar to FBU's format? If there is no significant gain, I=20
> > would prefer keeping the format similar to the HI message in=20
> > RFC 5268. We can't obviously re-use data structures. For=20
> > example, the flags in HI and flags in FBU would overlap. That=20
> > would be a problem.
>=20
> No, we cannot re-use data structures, but all the MH messages=20
> would have
> a consistent format.
>=20
> Put anothr way, what do we gain by keeping the ICMP header fields?
>=20
> The purpose of the Sequence Number field is the same in FBU=20
> and HI, but
> we would end up having two different fields (Sequence Number,
> Identifier) for the purpose.
>=20
> I would like to avoid having different fields for the same=20
> purpose when
> using the same message header type (i.e., MH).
>=20
> >=20
> > I want to understand why the MH messages have to be=20
> > consistent. We after all have 12 messages already defined=20
> > (with three more on the way). They all have very different=20
> > message formats. The only exception is BU and FBU.
>=20
> They don't have to be the same across protocol=20
> specifications. Within a
> same protocol, it would be good to have the consistent format. See the
> comment above regarding using Seq # vs. Identifier.
>=20
> Thanks,
>=20
> -Rajeev
>=20
>=20
> >=20
> > Vijay
> >=20
> >=20
>=20
>=20
> This email and any attachments may contain legally privileged=20
> and/or confidential information of Starent Networks, Corp.=20
> and is intended only for the individual or entity named in=20
> the message.  The information transmitted may not be used to=20
> create or change any contractual obligations of Starent=20
> Networks, Corp.  Any review, retransmission, dissemination or=20
> other use of, or taking of any action in reliance upon this=20
> e-mail and its attachments by persons or entities other than=20
> the intended recipient is prohibited. If you are not the=20
> intended recipient, please notify the sender immediately --=20
> by replying to this message or by sending an email to=20
> [email-masked] -- and destroy all copies of=20
> this message and any attachments without reading or=20
> disclosing their contents. Thank you.
>=20

Date: Fri, 27 Feb 2009 23:41:46 +0900
From: Hidetoshi Yokota <[email-masked]>
To: Vijay Devarapalli <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Mipshop] Comments on draft-ietf-mipshop-pfmipv6-02.txt

This is a multi-part message in MIME format.
--------------050402010403060707050103
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

Hi Vijay,

Thanks a lot for your detailed review and very sorry for this late
response. A tentatively revised version is attached and the responses to
your comments are in line:

Vijay Devarapalli wrote:
> Hello,
> 
> I reviewed the document. It still needs a fair amount of work before we 
> can start a WG last call.
> 
>>    This document specifies the usage of Fast Mobile IPv6 (FMIPv6) when
>>    Proxy Mobile IPv6 is used as the mobility management protocol.
>>    Necessary extensions are specified for FMIPv6 to support the scenario
>>    when the mobile node does not have IP mobility functionality and
>>    hence is not involved with either MIPv6 or FMIPv6 operations.
> 
> Perhaps you should briefly mention what FMIPv6 does.

The following paragraph is added:

   Fast Handovers for Mobile IPv6 (FMIPv6) [RFC5268bis] describes the
   protocol to reduce the handover latency for Mobile IPv6 by allowing a
   mobile node to send packets as soon as it detects a new subnet link
   and by delivering packets to the mobile node as soon as its
   attachment is detected by the new access router.  This document
   describes necessary extensions to FMIPv6 for operations in the PMIPv6
   domain in order to minimize handover delay and packet loss as well as
   to transfer network-resident contexts.

>> 2.  Introduction
>>
>>    Proxy Mobile IPv6 [RFC5213] provides IP mobility to a mobile node
>>    that does not possess Mobile IPv6 [RFC3775] functionality.  
> 
> s/Mobile IPv6 [RFC3775] functionality/Mobile IPv6 [RFC3775] mobile node 
> functionality/

Revised.

>> A proxy
>>    agent in the network performs the mobility management signaling on
>>    behalf of the mobile node.  This model transparently provides
>>    mobility for Mobile Nodes within a PMIPv6 domain.  
> 
> You have used "mobile node" earlier in the paragraph.

Revised.

>> Nevertheless, the
>>    basic performance of PMIPv6 in terms of handover latency and packet
>>    loss is considered not any different from that of Mobile IPv6.
>>
>>    Fast Handovers for Mobile IPv6 is specified in [RFC5268bis].  This
>>    document applies the same Fast Handovers protocol for Proxy Mobile
>>    IPv6 (PFMIPv6), in order to provide handover delay, packet loss and
>>    transfer of network-resident contexts.  
> 
> You should use "minimize handover delay, reduce packet loss, etc...". It 
> would be bad if the protocol provides handover delay and packet loss. :)

Revised.

>>    HO-Initiate:
>>         A generic signaling that indicates the handover of the MN sent
>>         from the P-AN to the PMAG.  While this signaling is dependent on
>>         the access technology, it is assumed that HO-Initiate can carry
>>         the information to identify the MN and to assist the PAR resolve
>>         the NAR (e.g., the new access point or base station to which the
>>         MN is moving).
> 
> Need to explicitly mention that this message is not being defined in 
> this document.

The following sentence is added:

Detailed definition of this message is outside the scope of this document.

>>
>>                                   +----------+
>>                                   |   LMA    |
>>                                   |          |
>>                                   +----------+
>>                                     /      \
>>                                    /        \
>>                                   /          \
>>                       +........../..+      +..\..........+
>>                       . +-------+-+ .______. +-+-------+ .
>>                       . |   PAR   |()_______)|   NAR   | .
>>                       . |  (PMAG) | .      . |  (NMAG) | .
>>                       . +----+----+ .      . +----+----+ .
>>                       .      |      .      .      |      .
>>                       .   ___|___   .      .   ___|___   .
>>                       .  /       \  .      .  /       \  .
>>                       . (  P-AN   ) .      . (  N-AN   ) .
>>                       .  \_______/  .      .  \_______/  .
>>                       .      |      .      .      |      .
>>                       .   +----+    .      .   +----+    .
>>                       .   | MN |  ---------->  | MN |    .
>>                       .   +----+    .      .   +----+    .
>>                       +.............+      +.............+
>>
>>                Figure 1: Reference network for fast handover
> 
> You have to mention somewhere that "P-AN" and "N-AN" refer to the radio 
> elements of the access network. The PAR and the NAR are the first hop 
> routers for the mobile node. So when you say there is a network between 
> the MN and the PAR/NAR, it is confusing.

The following definition is added in the Terminology section:

   Access Network (AN):
        A network composed of link-layer access devices such as access
        points or base stations providing access to the Access Router
        (AR) connected to it.

>>                                             PMAG        NMAG
>>           MN         P-AN       N-AN        (PAR)       (NAR)     LMA
>>           |           |          |            |           |        |
>>           |  Report   |          |            |           |        |
>>      (a)  |-(MN ID,-->|          |            |           |        |
>>           | New AP ID)|          |            |           |        |
>>           |           |     HO Initiate       |           |        |
>>      (b)  |           |--(MN ID, New AP ID)-->|           |        |
>>           |           |          |            |           |        |
>>           |           |          |            |    HI     |        |
>>      (c)  |           |          |            |-(MN ID, ->|        |
>>           |           |          |            | MN IID, LMAA)      |
>>           |           |          |            |           |        |
>>      (d)  |           |          |            |<---HAck---|        |
>>           |           |          |            |  (MN ID)  |        |
>>           |           |          |            |           |        |
>>           |           |          |            |HI/HAck(optional)   |
>>      (e)  |           |          |            |<- - - - ->|        |
> 
> What is this HI/HACK for? Later in the text you say
> 
>    (e)  The NAR may optionally request the PAR to buffer or forward
>         packets by setting U or F flags in the HI message, respectively.
> 
> Is this exchange just for indicating the two flags, 'U' and 'F'? Is 
> there anything else sent in this HI/HACK exchange?

The later the timing of buffering becomes, the shorter the handover
latency will be, so now the spec clarifies that HI/HAck exchanges could
happen multiple times: one for the context transfer, another for the
trigger for buffering.

>         This step may be combined with steps (c) and (d).

The above sentence was deleted.

> How? In step (c), the HI goes from PAR to NAR. In step (e), the HI goes 
> from NAR to PAR. How can you combine the two? Or did you mean, the NAR 
> can send a HI as soon as it receives a HI from the PAR before responding 
> with a HACK? It is confusing.

Step (e) now has the following sentences:

   (e)  If it is preferred that the timing of buffering or forwarding
        should be later than step (c), the NAR may optionally request
        the PAR at a later and appropriate time to buffer or forward
        packets by setting U or F flags in the HI message, respectively.

>>      (f)  |           |          |            |==DL data=>|        |
> 
> Don't you have to show the "DL data" from the LMA to the PAR before 
> showing the "DL data" from the PAR to the NAR?

Revised.

>>           |           |          |            |           |        |
>>      (g) ~~~          |          |            |           |        |
>>          ~~~          |          |            |           |        |
>>           |   MN-AN connection   |    AN-MAG connection   |        |
>>      (h)  |<---establishment---->|<----establishment----->|        |
>>           |           |          |  (substitute for UNA)  |        |
>>           |           |          |            |           |        |
>>      (i)  |<==================DL data=====================|        |
>>           |           |          |            |           |        |
>>      (j)  |===================UL data====================>|#       |
>>           |           |          |           #|<==========|#       |
>>           |           |          |           #|===================>|
>>           |           |          |            |HI/HAck(optional)   |
>>      (k)  |           |          |            |<- - - - ->|        |
> 
> I did not understand the purpose of this HI/HACK at all.

The intention of this step is to send a trigger to the PAR to tear down
the forwarding tunnel. But, it should happen after the PBU/PBA. This
step was removed.

>>    (b)  The previous access network (P-AN), to which the MN is currently
>>         attached, indicates the handover of the MN to the PAR (PMAG).
> 
> Again, mention that this message is out of scope.

The following sentence is added:

        Detailed definition and specification of this message are
        outside the scope of this document.

>>    (k)  The PAR MAY send the HI message to indicate that the packet
>>         forwarding is completed.
> 
> When does the PAR send this message? The PAR has no idea that the 
> binding cache entry at the LMA has been updated with the NAR's address 
> and therefore no more traffic meant for the MN will come to the PAR. I 
> suggest removing this.

Removed.

>>    If the network that the MN has moved to does not support PMIPv6 but
>>    only MIPv6 (i.e. there exists a MIPv6 HA) and the MN supports MIPv6
>>    at the same time, the MN and HA can exchange BU/BA instead of PBU/PBA
>>    in steps (j) and (k).  If this is the case, the LMA and HA will most
>>    likely be collocated and the LMA (HA) address should be maintained in
>>    the new network for communication continuity.  Since the LMA (HA)
>>    address is transferred to the NAR in step (c), the MN can retrieve it
>>    at or after step (g) by e.g. the authentication or DHCP procedure
>>    (not shown in the figure).
> 
> Perhaps this paragraph should be moved to an appendix that explains what 
> happens when the mobile node moves out of a PMIPv6 domain. It is 
> distracting in the current position.

This paragraph was moved to Appendix A.2.

>>    (g)  The PAR MAY send the HI message to indicate that the packet
>>         forwarding is completed.
> 
> Same issue as before. How does the PAR figure out when to send the HI 
> message?

Removed.

>>    Also, in step (c), the NAR could send an unsolicited HAck message to
>>    the PAR, which then triggers the HI message from the PAR.  By doing
>>    so, the directions of HI/HAck messages are aligned with the
>>    predictive (PAR-initiated) fast handover.  Further study is needed if
>>    this call flow is more appropriate than the current one.
> 
> Why have two mechanisms for the same? The NAR could just send a HI and 
> get the response in a HACK message. Why bother sending an unsolicited 
> HACK message? And what do you mean by "Further Study"? Are you saying we 
> don't enough to say whether the NAR should send a HI message or an 
> unsolicited HACK message for a reactive handover? So both options are 
> allowed. (?)

There was a debate with Rajeev whether the direction of the HI should
always be the same (from PAR to NAR) and not the other way. FFS was put
for that moment, but now it's time to resolve it:-) I don't mind
deleting this sentence, but let's discuss it beforehand.

>> 6.1.1.  Handover Initiate (HI)
>>
>>    This section defines extensions to the HI message in [RFC5268bis].
>>    The format of the Message Data field in the Mobility Header is as
>>    follows:
>>
>>       0                   1                   2                   3
>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>                                      +---------------+-+-+-----------+
>>                                      |           Sequence #          |
>>      +-+-+-+-------------------------+---------------+-+-+-----------+
>>      |S|U|F|                 Reserved                |     Code      |
>>      +-+-+-+-----------------------------------------+---------------+
>>      |                                                               |
>>      .                                                               .
>>      .                       Mobility options                        .
>>      .                                                               .
>>      |                                                               |
>>      +---------------------------------------------------------------+
>>
>>    IP Fields:
>>
>>    Source Address
>>
>>                        The IP address of PMAG or NMAG
>>
>>    Destination Address
>>
>>                        The IP address of the peer MAG
>>
>>    Message Data:
>>
>>    Sequence #  Same as [RFC5268bis].
>>
>>    S flag      Must be set to zero (defined in [RFC5268bis]).
>>
>>    U flag      Buffer flag.  Same as [RFC5268bis].
>>
>>    F flag      Forwarding flag.  Used to request to forward the packets
>>                for the MN.
> 
> You should describe the 'F' flag here and refer to 5268bis for all other 
>  fields.

I put the reference to 5268bis at all the relevant fields.

>>    Code        If F flag is not set, the Code MUST be set to zero.
>>                Otherwise, the Code value has the following meaning:
>>
>>                          0: Reserved
>>
>>                          1: Forwarding is not requested
>>
>>                          2: Request forwarding
>>
>>                          3: Indicate the completion of forwarding
> 
> There is an issue here. 5268bis already has semantics for code set to 
> '0' and '1'. I think you should start at '2' in this document.

Revised.

>> 6.1.2.  Handover Acknowledge (HAck)
>>
>>    This section defines extensions to the HAck message in [RFC5268bis].
>>    The format of the Message Data field in the Mobility Header is as
>>    follows:
>>
>>
>>       0                   1                   2                   3
>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>                                      +---------------+---------------+
>>                                      |           Sequence #          |
>>      +-------------------------------+---------------+---------------+
>>      |                       Reserved                |     Code      |
>>      +-----------------------------------------------+---------------+
>>      |                                                               |
>>      .                                                               .
>>      .                       Mobility options                        .
>>      .                                                               .
>>      |                                                               |
>>      +---------------------------------------------------------------+
> 
> Since this document is not making any change to the HACK message format, 
> do you need to show the message here? Perhaps you can just refer to 
> 5268bis.

Revised.

>>                        5: Context Transferred successfully, more context
>>                        available
> 
> What does this mean? Is it saying there will be more unsolicited HACK 
> messages that follow with more context? If so, how are they all 
> correlated at the NAR? If not, does it mean the NAR has to send more HI 
> messages to get more context from the PAR?

The intention here is that the amount of the context to transfer could
be very large, so it is allowed to send the HI messages multiple times.

>> 6.2.  Mobility Options
>>
>> 6.2.1.  Context Request Option
>>
>>    This option is sent in the HI message to request context information
>>    on the MN.
>>
>>       0                   1                   2                   3
>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>      +---------------+---------------+---------------+---------------+
>>      |  Option-Type  | Option-Length |           Reserved            |
>>      +---------------+---------------+-------------------------------+
>>      |  Req-type-1   | Req-length-1  |  Req-type-2   | Req-length-2  |
>>      +---------------------------------------------------------------+
>>      |                              ...                              |
> 
> What does the above format mean? Where is the data in each request? Is 
> it just request type and request length? Does Req-type use the same name 
> space as mobility options? If so, this creates a problem. Mobility 
> options are supposed to be carried in a mobility header message. Here 
> you carrying the mobility options in another mobility option (Context 
> Request Option).
> 
> If you are not using the same name space as mobility options, are you 
> creating a new name space for the "Req-type" field?
> 
>>    Context Request Option is typically used for the reactive (NAR-
> 
> How come there is no "Context Response option" defined?
> 
>>    In the case where there are only Req-type-n and Req-length-n fields,
>>    the value of the Req-length-n is set to zero.  If additional
>>    information besides the Req-type-n is necessary to uniquely specify
>>    the requested context, such information follows after the
>>    Req-length-n.  For example, when the requested context is the Vendor-
>>    Specific Option defined in Section 6.2.8, the requested option format
>>    looks as follows:
>>
>>      |                              ...                              |
>>      +---------------+---------------+-------------------------------+
>>      | Req-type-N=19 | Req-length-N=6|           Vendor-ID           |
>>      +-------------------------------+-------------------------------+
>>      |           Vendor-ID           |           Sub-Type            |
>>      +---------------------------------------------------------------+
>>      |                              ...                              |
> 
> I don't think a Vendor Specific Mobility Option can be a sub-option of 
> the Context Request Mobility Option.

This option is to request necessary contexts typically from the NAR, so
this doesn't include any values, which are supposed to be transferred
later from the PAR. This is similar to the DHCP Option Request Option.

>> 6.2.2.  Local Mobility Anchor Address (LMAA) Option
>>
>>    This option is used to transfer the Local Mobility Anchor Address
>>    (LMAA), with which the MN is currently registered.  The detailed
>>    definition of the LMAA is described in [RFC5213].
>>
>>       0                   1                   2                   3
>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |  Option-Type  | Option-Length |          Reserved             |
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |                                                               |
>>      +                                                               +
>>      |                                                               |
>>      +                 Local Mobility Anchor Address                 +
>>      |                                                               |
>>      +                                                               +
>>      |                                                               |
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Why don't you add a field here that indicates whether you are carrying 
> the IPv4 address or the IPv6 address of the LMA? I don't like the fact 
> that you have a LMA address option for carrying the IPv6 address of the 
> LMA, and another IPv4 address option that can carry either the IPv4 
> address of the LMA or the mobile node.

I see your point, but the "IPv4 Address Option" defined in 6.2.3 has the
Option-code to carry the IPv4 address of the LMA. Do you still prefer to
carry it by the LMAA option?

>> 6.2.4.  Home Network Prefix Option
>>
>>    This option is used to transfer the home network prefix that is
>>    assigned to the MN in the P-AN.  The format of this option follows
>>    the Home Network Prefix Option defined in [RFC5213].
> 
> Re-word the last sentence to
> 
>   The Home Network Prefix Option defined in [RFC5213] is used for this.

Revised.

>> 6.2.5.  Mobile Node Interface Identifier (MN IID) Option
>>
>>    This option is used to transfer the interface identifier of the MN
>>    that is used in the P-AN.  The format of this option follows the
>>    Mobile Node Interface Identifier Option defined in [RFC5213].
> 
> Re-word the last sentence as

Revised.

>   The Mobile Node Interface Identifier Option defined in [RFC5213] is
>   used for this.
> 
>> 6.2.6.  Link-local Address Option
>>
>>    This option is used to transfer the link-local address of the PAR
>>    (PMAG).  The format of this option follows the Link-local Address
>>    Option defined in [RFC5213].
> 
> Same as above.

Revised.

>> 7.  Security Considerations
>>
>>    Security issues for this document follow those for PMIPv6[RFC5213]
>>    and FMIPv6[RFC5268bis].  In PMIPv6, MAG and LMA are assumed to share
>>    security association.  In FMIPv6, the access routers (i.e., the PMAG
>>    and NMAG in this document) are assumed to share security association.
>>    No new security risks are identified.  Support for integrity
>>    protection using IPsec is required, but support for confidentiality
>>    is not necessary.
> 
> I think you need support for confidentiality protection if there is some 
> sensitive MN context is being transfered. You should say 
> "Confidentiality protection SHOULD be used if sensitive context related 
> to the mobile node is being transferred".

Revised.

>> 8.  IANA Considerations
>>
>>    This document defines two new mobility options, which are described
>>    in Section 6.2.  The Type value for these options are assigned from
>>    the same numbering space as allocated for the other mobility options,
>>    as defined in [RFC3775].
>>
>>     Mobility Options
>>     Value  Description                            Reference
>>     -----  -------------------------------------  -------------
>>     TBD1   Context Request Option                 Section 6.2.1
>>     TBD2   Local Nobility Anchor Address Option   Section 6.2.2
>>     TBD3   IPv4 Address Option                    Section 6.2.3
> 
> This would need revision if we conclude that existing mobility options 
> cannot become sub-options of the Context Request mobility option.

I haven't changed this part, yet. Let us hear your opinion about the
usage of this option.

Thanks again for your time and appreciate your further comments.

Regards,
-- 
Hidetoshi

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

--------------050402010403060707050103
Content-Type: text/plain;
 name="draft-ietf-mipshop-pfmipv6-03.txt"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="draft-ietf-mipshop-pfmipv6-03.txt"

--------------050402010403060707050103--