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

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Mon, 20 May 2013 15:04 UTC

Return-Path: <cjbc@it.uc3m.es>
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 ED91621F8C38 for <netext@ietfa.amsl.com>; Mon, 20 May 2013 08:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 eSClE3hFA6Jv for <netext@ietfa.amsl.com>; Mon, 20 May 2013 08:04:25 -0700 (PDT)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id E486C21F933B for <netext@ietf.org>; Mon, 20 May 2013 08:04:24 -0700 (PDT)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CFC321183F9A; Mon, 20 May 2013 17:04:23 +0200 (CEST)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id B9BBA9D360B; Mon, 20 May 2013 17:04:23 +0200 (CEST)
Message-ID: <1369062263.4503.40.camel@acorde.it.uc3m.es>
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: Basavaraj Patil <bpatil1@gmail.com>
Date: Mon, 20 May 2013 17:04:23 +0200
In-Reply-To: <CAA5F1T3X29yeRBgzd4aq3QnkA80Ov-7JBf2K5O__nTRSa1ZeqQ@mail.gmail.com>
References: <CAA5F1T3X29yeRBgzd4aq3QnkA80Ov-7JBf2K5O__nTRSa1ZeqQ@mail.gmail.com>
Organization: Universidad Carlos III de Madrid
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.4.4-3
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19880.007
X-TM-AS-Result: No--22.436-7.0-31-1
X-imss-scan-details: No--22.436-7.0-31-1
Cc: "netext@ietf.org" <netext@ietf.org>, "draft-ietf-netext-pd-pmip@tools.ietf.org" <draft-ietf-netext-pd-pmip@tools.ietf.org>
Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip6-06
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: cjbc@it.uc3m.es
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: Mon, 20 May 2013 15:04:30 -0000

Hi Raj,

Some additional responses inline below (as Joy mentioned, we believe
that everything is clearer in the new version, but just in case).

On Wed, 2013-04-03 at 12:59 -0500, Basavaraj Patil wrote:
> 
> 
> 
> 
> 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?

[Carlos] It is 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?

[Carlos] We have clarified this in the new version.
> 
> 
> 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?

[Carlos] Right, two deployment models are considered: one in which the
MAG acts a DHCPv6 Delegating Router (i.e., server) and another in which
the MAG acts as DHCPv6 Relay Agent and the LMA as Delegating Router.
This has been further clarified in the new version.
> 
> 
> 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?

[Carlos] Yes, the prefixes are 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)?

[Carlos] This has been further revised and clarified in the new version.
> 
> 
> 6. Is the assumption that the DHCP server functionality resides either
>    at the MAG or the LMA in this I-D?

[Carlos] Yes. It should be now clearer with the updates we have done in
the text.
> 
> 
> 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.
> 
> 
[Carlos] This should be now clear.
> 
Thanks for your comments!

Carlos
> 
> 
> 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
> 
> 
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext