[Mipshop] Review of draft-ietf-mipshop-fmip-ptp-00

[Vijay Devarapalli <[e-mail]>]

Hello,

I reviewed the draft. Here are some comments.

> 3.  Problem Statement
>
>    The following are operations relating to prefix management as per
>    [RFC5568]:
>
>    o  Movement detection.  The protocol enables a MN to quickly detect
>       that it has moved to a new subnet by providing the new access
>       point and the associated subnet prefix information when the MN is
>       still connected to its current subnet.  For instance, the MN may
>       discover available access points using link-layer specific
>       mechanisms (i.e., a "scan" in WLAN) and then request subnet
>       information corresponding to one or more of those discovered
>       access points.  The MN sends a Router Solicitation for Proxy
>       Advertisement (RtSolPr) to its access router to resolve one or
>       more Access Point Identifiers (AP-ID)to subnet-specific
>       information.  In response, the access router sends a Proxy Router
>       Advertisement (PrRtAdv) message containing one or more [AP-ID, AR-
>       Info] tuples, which the MN can use in readily detecting movement:
>       when attachment to an access point with AP-ID takes place, the MN
>       knows the corresponding new router's coordinates including its
>       prefix, IP address, and L2 address.

You might want to mention that this is as per RFC 5568. No changes to 
the actual movement detection procedure.

>    In shared link model, the prefix and NCoA are manually configured in
>    the previous access router.

RFC 5568 does not say this information needs to be manually configured. 
It just says that the PAR manages to resolve the Access Point ID to a 
particular NAR and the prefix associated with the NAR. The NCoA is 
definitely not configured on the PAR, since the NCoA could contain the 
mobile node's interface identifier.

This is not a problem because there is
>    only a small number of adjacent access routers, and the prefix is
>    shared by many mobile nodes.  However, it becomes a big problem when
>    trying to configure prefixes manually in point-to-point link model.
>    In this model, each MN has one or more dedicated prefixes, that is,
>    different MNs have different prefixes.  The prefixes could be
>    allocated dynamically.  When a MN attaches to an AR, the AR should
>    allocate one or more dedicated prefixes for it; when the MN detaches
>    from the AR, the MN's prefixes are released, and can be reused by
>    other MNs.  The number of unique prefixes in this operation can be
>    huge.

Suggest replacing the above paragraph with

   In the shared link mode, the PAR only needs to figure out what IPv6
   prefix is advertised by the NAR. In most cases, there would only be
   a small set of adjacent NARs and the PAR would be able to obtain
   this information easily. In the point-to-point link mode, the NAR
   has access to a pool of IPv6 prefixes and these prefixes are assigned
   dynamically to each mobile node's point-to-point link. Therefore it
   becomes difficult for the PAR to figure out which IPv6 prefix is
   going to be assigned to a particular mobile node when point-to-point
   link mode is used.

>    NCoA formulation in point-to-point links requires a PAR to
>    dynamically request a dedicated prefix from a NAR, and then advertise
>    it to the MN using a Proxy Router Advertisement (PrRtAdv) message.
>    [RFC5568] does not specify such dependencies.

Rewrite this as

   For the mobile node to configure an NCoA, the PAR sends a Proxy
   Router Advertisement to the mobile node. This requires that for
   point-to-point links, the PAR MUST first contact the NAR to for
   the dedicated prefix and then advertise the prefix to the mobile
   node. This is an extension to RFC 5568 to support point-to-point
   links.

>    The NAR MAY use DHCPv6 prefix delegation to request/ release prefixes
>    from a DHCPv6 server.  The DHCPv6 messages are triggered by the HI
>    for prefix request.  The NAR MAY also use AAA prefix delegation to
>    request/ release prefixes for this MN from an AAA server.  The
>    mechanisms for the NAR to acquire the prefixes are outside the scope
>    of this document.

This whole paragraph should be delete. This document should not care 
about how the NAR manages prefixes or where it gets the prefixes from.

>    Lifetime in Dedicated Prefix Option Figure 1 is used to prevent

You might want to add a reference to section 5.3 instead of the figure.

> 4.2.  Reactive Mode
>
>    In the reactive mode, there are two cases.  A MN receives PrRtAdv
>    message or otherwise.
>
>    o  The MN receives PrRtAdv message and formulates NCoA before
>       attaching to the NAR.  The MN and the NAR operate in line with the
>       procedure defined in [RFC5568].
>
>    o  The MN can't formulate NCoA before attaching to the NAR.  IP
>       connectivity should be established first.  The MN can configure
>       its IP address using stateless address configuration, or using
>       stateful address configuration.  In the former case, the NAR
>       SHOULD send un-solicited RA to expedite MN's address
>       configuration.  Once NCoA formulation is finished, the MN operates
>       according to [RFC5568].
>
>    In both cases, the MN formulates NCoA from the dedicated prefix.
>    Since the MN has already handed over to the NAR, this prefix is
>    retained.

The above is confusing. I suggest re-writing the entire section as follows.

4.2.  Reactive Mode

    In the reactive mode, there are two cases.

    o  In the first case, the MN receives the PrRtAdv message while
       still attached to the PAR.  The MN is then able to formulate
       NCoA before attaching to the NAR.  The MN and the NAR operate
       as per the procedures defined in [RFC5568].

    o  In the second case, the MN does not receive a PrRtAdv before
       attaching to the NAR. The MN can configure its IP address
       using stateless or stateful address configuration. In the
       former case, the NAR SHOULD send un-solicited RA to expedite
       MN's address configuration.  Once NCoA formulation is finished,
       the MN operates according to [RFC5568].


    In both cases, the MN formulates NCoA from the dedicated prefix.
    Since the MN has already handed over to the NAR, this prefix is
    retained.

> 5.3.  Dedicated Prefix Option
>
>        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
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |      Type     |    Length     | Option-Code   | Prefix Length |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>      Option-Code
>                 1    Dedicated Prefix

I don't see a need for an "option-code". The option is already for a 
dedicated prefix. Not sure why you need to the code to say the same.

>
> 7.  IANA considerations
>
>    This document extends existing HI/HAck messages, new HI Code (TBD1)
>    and HAck Code (TBD2) values need to be assigned by IANA.

You need to identify the name of the registry. In this case, it would be 
"Handover Initiate Status Codes" registry.

Please submit a revised document with these comments addressed.

Vijay