[netext] Review of I-D: draft-ietf-netext-pd-pmip6-06

Basavaraj Patil <bpatil1@gmail.com> Wed, 03 April 2013 17:59 UTC

Return-Path: <bpatil1@gmail.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765B121F8BF2 for <netext@ietfa.amsl.com>; Wed, 3 Apr 2013 10:59:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUBLz25hnqjy for <netext@ietfa.amsl.com>; Wed, 3 Apr 2013 10:59:23 -0700 (PDT)
Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 70D4121F8BDD for <netext@ietf.org>; Wed, 3 Apr 2013 10:59:23 -0700 (PDT)
Received: by mail-oa0-f45.google.com with SMTP id o6so1803068oag.4 for <netext@ietf.org>; Wed, 03 Apr 2013 10:59:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=zYLxrIjYhoY8Ftxauf1xIhfhY6A4ZtGp8/92DDxkx0c=; b=zzQ97nizKJzO3/asnoPEqiMk0kLOWiii+f0S4TgtJefE6bxyc4sBxHSWFoFZ9stXcU QraeaGuFBvyHduqG8TO05N2UTbKnZc1qdn1UGcGQR8XCtrzBzSN4SiZl73PpTewVkr9F BlMFGcuWbY6mBf4dj5w7y/o1dor1wWfWd4hsZCKQoupzHInP26bGAcpFlR2F9lgERxbi YgE9NrQNlBOTFVIax0x/AKplNAZnHPi6yEWg9q5tOLpGXIYz57Y6EVk42vxXcj6YQoav eFZPtvrSMjA5koGmR56HSzZNFyBTpQoAdI3A8BLCjDYyCw3xWjHWiJ4HFIdE/mtn1Nv0 aKzQ==
MIME-Version: 1.0
X-Received: by 10.60.28.37 with SMTP id y5mr1770434oeg.134.1365011963008; Wed, 03 Apr 2013 10:59:23 -0700 (PDT)
Received: by 10.76.127.34 with HTTP; Wed, 3 Apr 2013 10:59:22 -0700 (PDT)
Date: Wed, 03 Apr 2013 12:59:22 -0500
Message-ID: <CAA5F1T3X29yeRBgzd4aq3QnkA80Ov-7JBf2K5O__nTRSa1ZeqQ@mail.gmail.com>
From: Basavaraj Patil <bpatil1@gmail.com>
To: "netext@ietf.org" <netext@ietf.org>
Content-Type: multipart/alternative; boundary="e89a8fb1f7f02b608904d9789d47"
Cc: "draft-ietf-netext-pd-pmip@tools.ietf.org" <draft-ietf-netext-pd-pmip@tools.ietf.org>
Subject: [netext] Review of I-D: draft-ietf-netext-pd-pmip6-06
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2013 17:59:24 -0000

Questions:

1. In the terminology section:
   "The DMNP is an IPv4 or an IPv6 prefix delegated to a mobile router
      and advertised in the mobile network."

      What is the mobile network being refered to in this statement?
      Is it the PMIP6 domain itself? Or is it the network that the
      mobile router is hosting?

2. In Sec 4.3.1:
   "It is possible that the delegated prefix(es) may
       have been assigned to the MAG by the LMA during this procedure of
       PMIPv6 tunnel establishment.  That is the MAG may include one (or
       more) Delegated Mobile Network Prefix (DMNP) mobility options
       which MUST be set to the unspecified IPv6 address "::" in the PBU
       to request the delegated prefix(es).  The LMA assigns a new set
       of DMNP(s) in PBA message."

       Not sure what your assumptions are here. Why does the LMA
       assign delegated prefix(es) during normal RFC5213 PMIP6 tunnel
       establishment procedures?
       What would cause the MAG to include the DMNP option in the PBU
       at this stage (Step 2) of the session?

3. In Sec 4.3.1:
   " The mobile router, acting as a "Requesting Router" as described
       in [RFC3633], sends a DHCPv6 SOLICIT message including one or
       more IA_PD option(s) to the mobile access gateway (which has a
       "DHCPv6 Server" function) to acquire the delegated prefix(es)."

       Is there an assumption that the MAG is also the DHCPv6 server?
       The MAG could be a DHCP relay as well, right?

4. In Sec 4.3.1, step 5:
   "The LMA must set
       up forwarding for the delegated prefixes as reachable through the
       PMIPv6 tunnel."

       The LMA may or may not assign these delegated prefixes. The MAG
       could be the one assigning the delegated prefixes as per the
       description. Are those prefixes routable by the LMA?

5. In Sec 4.4.1, step 4:
   "If the mobile access
        gateway does not know the delegated prefix(es), then the
        delegated mobile network prefix in the DMNP option(s) MUST be
        set to the unspecified IPv6 address "::", "

How would the MAG know the delegated prefix(es)? Unless it is
just renewing the assigned prefix(es)?

6. Is the assumption that the DHCP server functionality resides either
   at the MAG or the LMA in this I-D?

7. In Sec 6.2 you state:
   "In order to receive these packets, the
      local mobility anchor MUST be the topological anchor of the MR's
      delegated mobile network prefix(es)."

      This should be made clear up front in order to avoid confusion
      about how forwarding is accomplished.



Editorial:

s/Proxy Mobile IPv6 enables IP mobility for a host without requiring
   its participation in any mobility signaling, being the network
   responsible for managing IP mobility on behalf of the host./ Proxy
   Mobile IPv6 enables IP mobility for a host without requiring
   its participation in any mobility signaling. Mobility elements in
   the network are responsible for managing IP mobility on behalf of
   the host.

s/However,
   Proxy Mobile IPv6 does not support assigning a prefix to a router and
   managing its IP mobility./However, Proxy Mobile IPv6 lacks the
   ability to assign a prefix to a router and  manage its IP
   mobility.

s/and be able to obtain IP mobility support for those IP addresses./
   and enable IP mobility support for the assigned IP address or
   prefixes.

s/However,
   this network-based mobility management support is specific to an IP
   host and currently there is no such network-based mobility management
   support for a mobile router with a cluster of IP hosts behind
it./However,
   the Proxy Mobile IPv6 based solution for  network-based mobility
   management is specific to IP hosts and does not provide similar
   functionality for a mobile router with a cluster of IP hosts behind
   it.

-Raj