Subject: [Mipshop] Comments on draft-ietf-mipshop-pfmipv6-05.txt

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 26 Jun 2009 15:58:13 -0700

Hello,

I went through the draft one more time before sending it to the IESG. I 
have one major comment and a number of minor comments. I think one more 
revision is needed before it can be sent to the IESG.

The major comment - I think we should introduce a flag in the HI message 
that says it is related to PFMIPv6 as opposed to FMIPv6. There are too 
many subtle differences between the processing of FMIPv6 HI and PFMIPv6 
HI messages. Having a flag that indicates this explicitly would be good.

In the Introduction section, rephrase

> 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.
> 

as

    This document
    describes necessary extensions to FMIPv6 to minimize handover delay
    and packet loss as well as to transfer to transfer network-resident
    context for a PMIPv6 handover.

In the following, you seem to say PAR resolves the NAR and then you talk 
about the access point or base station. It is not clear. In addition, 
the last sentence needs to be rephrased.

>    HO-Initiate:
>         A generic signaling message 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).  Definition of details
>         in the specification of this message is outside the scope of
>         this document.

How about the following?

    HO-Initiate:
         A generic signaling message, sent from the P-AN to the PMAG that
         indicates a MN handover.  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 PMAG
         resolve the NMAG and the new access point or the base station to
         which the MN is moving to.  The details of this message is
         outside the scope of this document.

In section 4, the following text does not say what the tunnel is for.

>    In order to improve the performance during handover (when operations
>    such as attachment to a new network and signaling between mobility
>    agents are involved), the PFMIPv6 protocol in this document specifies
>    a bi-directional tunnel between the Previous MAG (PMAG) and the New
>    MAG (NMAG).

So rephrase as

    In order to improve the performance during handover (when operations
    such as attachment to a new network and signaling between mobility
    agents are involved), the PFMIPv6 protocol in this document specifies
    a bi-directional tunnel between the Previous MAG (PMAG) and the New
    MAG (NMAG) to tunnel packets meant for the mobile node.

Replace

>    Since a MN is not directly involved with IP mobility protocol
>    operations, it follows that the MN is not directly involved with fast
>    handover procedures either.  Hence, the messages involving the MN in
>    [RFC5268bis] are not used when PMIPv6 is in use.  The Router
>    Solicitation for Proxy Advertisement (RtSolPr) and Proxy Router
>    Advertisement (PrRtAdv) are exchanged between the MN and PAR for the
>    MN to formulate the New Care-of Address (NCoA) in advance.  Fast
>    Binding Update (FBU) and Fast Binding Acknowledgment (FBack) are also
>    exchanged between these nodes to request the PAR to forward packets
>    to the NAR.  The Unsolicited Neighbor Advertisement (UNA) is sent
>    from the MN to NAR to forward the packets to the MN.  These messages
>    are not applicable in the PMIPv6 context.

with

    Since a MN is not directly involved with IP mobility protocol
    operations, it follows that the MN is not directly involved with fast
    handover procedures either.  Hence, the messages involving the MN in
    [RFC5268bis] are not used when PMIPv6 is in use.  More specifically,
    the Router Solicitation for Proxy Advertisement (RtSolPr), the Proxy
    Router Advertisement (PrRtAdv), Fast Binding Update (FBU), Fast
    Binding Acknowledgment (FBack) and the Unsolicited Neighbor
    Advertisement (UNA) messages are not applicable in the PMIPv6
    context.

>    (f)  If the F flag is set in the previous step, a bi-directional
>         tunnel is established between the PAR and NAR and packets
>         destined for the MN are forwarded from the PAR to the NAR over
>         this tunnel.  After decapsulation, those packets may be buffered
>         at the NAR.  If the connection between the N-AN and NAR has
>         already been established, those packet may be forwarded towards
>         the N-AN; this is access technology specific.

If the MN has not attached to N-AN, yet, what happens to the forwarded 
packets? If the N-AN required to buffer too? Or does the N-AN drop the 
packets? This needs to be clarified.

>    The encapsulation type for these user packets SHOULD follow that used
>    in the tunnel between the LMA and MAG (e.g., IPv6-in-IPv6 [RFC5213]
>    or GRE [GREKEY]).

I guess you need to mention UDP encapsulation too, in case an UDP tunnel 
is setup between the PMAG and the NMAG.

In section 4.2,

>  For the uplink packets, the NMAG SHOULD
>    redirect them from the MN towards the PMAG and the PMAG sends them to
>    the LMA.

It should be "reverse tunnel" to the PMAG. Not "redirect" to the PMAG.

>    Code        [RFC5268bis] defines this field and its values 0 and 1.
>                In this specification, if F flag is not set, this field
>                MUST be set to zero.  Otherwise, it has the following
>                meaning:
> 
>                          2: Forwarding is not requested
> 
>                          3: Request forwarding
> 
>                          4: Indicate the completion of forwarding

When is code '4' used? I couldn't find the corresponding text that 
explains when the code is set to '4' and what the receiving node needs 
to do.

>    Code
>                Code values 0 through 4 and 128 through 130 are defined
>                in [RFC5268bis].  In this specification, the meaning of
>                Code value 0 is modified, 128 through 130 are reused, and
>                5, 6, 131 and 132 are newly defined.
> 
>                        0: Handover Accepted
> 
>                        5: Context Transfer Successful or Accepted
> 
>                        6: All available Context Transferred
> 
>                        128: Handover Not Accepted, reason unspecified
> 
>                        129: Administratively prohibited
> 
>                        130: Insufficient resources
> 
>                        131: Requested Context Not Available
> 
>                        132: Forwarding Not Available

What does "Forwarding Not Available" mean? When is this set? Is the MAG 
that sent the HACK saying it won't forward the packets?

> 6.2.3.  IPv4 Address Option
> 
>    As described in Section 4.3, if the MN is IPv4-only mode or dual-
>    stack mode, the MN requires IPv4 home address (IPv4-MN-HoA).  This
>    option has alignment requirement of 4n.
> 
>       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 |  Option-Code  |    Reserved   |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                      IPv4 Address                             |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Option-Type    TBD3
> 
>    Option-Length  6
> 
>    Option-Code
> 
>                   0  Reserved
> 
>                   1  IPv4-MN-HoA

It looks like you don't need a "Option-Code" field here. This options 
seems to be only for carrying the MN's IPv4 address. There is no other use.

BTW, can't we re-use the IPv4 Home Address Option that we already have? 
See section 3.1.1 of RFC 5555.

> 6.2.4.  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.
> 
>       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 |  Option-Code  |    Reserved   |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                                                               |
>      +                      Interface Identifier                     +
>      |                                                               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Option-Type    TBD4
> 
>    Option-Length  10
> 
>    Option-Code    0

Same as above. Looks like you don't need the "Option-Code" field.

Vijay