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

Basavaraj Patil <bpatil1@gmail.com> Thu, 23 May 2013 18:16 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 AE6F221F958B for <netext@ietfa.amsl.com>; Thu, 23 May 2013 11:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.384
X-Spam-Level:
X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[AWL=0.214, 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 FGTlrp36nVQ8 for <netext@ietfa.amsl.com>; Thu, 23 May 2013 11:15:50 -0700 (PDT)
Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id E7CAE21F87D2 for <netext@ietf.org>; Thu, 23 May 2013 10:57:39 -0700 (PDT)
Received: by mail-oa0-f41.google.com with SMTP id n9so4841079oag.28 for <netext@ietf.org>; Thu, 23 May 2013 10:57:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XVSCwCZ2nI27eAcY0i2KYkTKOSa3vlNoEAKtOg2DKMI=; b=HBqfZ6ORySUvFC57pjHh/oQ0ap9euC+qv7+ws1fkD3B0p3BP9FMmOCfK37OG+Zndt2 N0je958lZ4ZAq4WUEADdVkypU9Sb3pu5xoMuTKg6C14otzrHkDJyobrYQR1w/idzOwwq wgkNoQTI3T5FaKtFTAFn8lJcnaoGJG1MFzXC/3UyGZGAUFvHRGE/FobJYgZq8TYXnMz9 nLiF2+g5gC+1pcC4TQIY90w0STkHc5I4iHXMYgxd/R3UPYEYUZ4UUUEpztoqaNiC7kuG ywkAzeK3ggilw78SjTRUu411zNC1s617wbUt0PKW5IQqjusJUhDUfXa4wlsPSxrpu824 O7QA==
MIME-Version: 1.0
X-Received: by 10.60.33.202 with SMTP id t10mr9197905oei.2.1369331859360; Thu, 23 May 2013 10:57:39 -0700 (PDT)
Received: by 10.76.103.235 with HTTP; Thu, 23 May 2013 10:57:39 -0700 (PDT)
In-Reply-To: <1369331695.4605.12.camel@acorde.it.uc3m.es>
References: <CAA5F1T3X29yeRBgzd4aq3QnkA80Ov-7JBf2K5O__nTRSa1ZeqQ@mail.gmail.com> <1369062263.4503.40.camel@acorde.it.uc3m.es> <CAA5F1T2XnKxfxWcVxXoAoQB6m3ruxXn8ha7pqHEKE4XeZ_1UxQ@mail.gmail.com> <1369331695.4605.12.camel@acorde.it.uc3m.es>
Date: Thu, 23 May 2013 12:57:39 -0500
Message-ID: <CAA5F1T1i9tqs1H3HbgCz34Fq5yYXBJYKr3LQ7=YaVSGhp0CjHg@mail.gmail.com>
From: Basavaraj Patil <bpatil1@gmail.com>
To: "cjbc@it.uc3m.es" <cjbc@it.uc3m.es>
Content-Type: multipart/alternative; boundary=089e013c66b40e950004dd666b5b
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
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: Thu, 23 May 2013 18:16:05 -0000

Thanks Carlos. That helps.
I am fine with the changes. Will initiate a WG LC on the I-D.

-Raj


On Thu, May 23, 2013 at 12:54 PM, Carlos Jesús Bernardos Cano <
cjbc@it.uc3m.es> wrote:

> Hi Raj, all,
>
> Some answers inline below.
>
> On Wed, 2013-05-22 at 14:40 -0500, Basavaraj Patil wrote:
> > Hi Carlos et al,
> >
> >
> > My comments inline:
> >
> >
> >
> >
> > On Mon, May 20, 2013 at 10:04 AM, Carlos Jesús Bernardos Cano
> > <cjbc@it.uc3m.es> wrote:
> >         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.
> >
> >
> > Raj> Okay.
> > However the current statement in the I-D:
> > "
> > The Delegated Mobile Network Prefix is an IPv4/IPv6 prefix
> > delegated to a mobile router and is hosted in the mobile network.
> > "
> > Would be better to say that this prefix is hosted by the PMIP6
> > mobility agent, i.e LMA.
> >
> [Carlos] There are two considerations here:
>
> 1. The prefix is configured in the mobile network. RA's are sent in
> those networks.
> 2. The LMA advertises that prefix into IGP. The LMA is the routing
> anchor, but is not hosting those prefixes. Text below (from Section
> 5.2.3):
>
>    o  The local mobility anchor MUST advertise a connected route into
>       the Routing Infrastructure for the IP prefixes delegated to all of
>       the mobile routers that it is serving.  This step essentially
>       enables the local mobility anchor to be a routing anchor for those
>       IP prefixes and be able to intercept IP packets sent to those
>       mobile networks.
> >
> >         >
> >         >
> >         > 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.
> >
> >
> > Raj> Section 4.3.1 no longer exists. Would have been easier if the
> > revised section was pasted here :(
>
> [Carlos] Sorry about this, my fault. We reorganized the document for
> readability and so moved sections around. The MAG will include the DMNP
> option in the PBU, triggered by:
>
> 1) MN's policy profile
> 2) Receives a trigger from DHCP module
>
> This is covered in Section 5.1.2.
>
> >
> >         >
> >         >
> >         > 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.
> >
> >
> > Raj> Okay.. Good.
> >
> >         >
> >         >
> >         > 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.
> >
> >
> > Raj> How?? Are those prefixes which the MAG delegates also anchored at
> > the LMA?
>
> [Carlos] This is covered in Section 5.2.3. Text below:
>
> 5.2.3:
>    o  The local mobility anchor MUST advertise a connected route into
>       the Routing Infrastructure for the IP prefixes delegated to all of
>       the mobile routers that it is serving.  This step essentially
>       enables the local mobility anchor to be a routing anchor for those
>       IP prefixes and be able to intercept IP packets sent to those
>       mobile networks.
>
> >
> >         >
> >         >
> >         > 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.
> >
> >
> > Raj> What is the new section in the document? Sec 4.4.1 is no longer
> > there.
>
> [Carlos] Again, sorry about this. This is also due to the reorganization
> of the document that we have done to improve readability.
>
> If the MAG has the list of delegated prefixes belonging to a session:
> - it includes the specific prefix values in the DMNP option
>
> If the MAG does not have the list of delegated prefixes belonging to a
> session:
> - it includes a value of 0::0 in the DMNP option
>
>
>
>
> >         >
> >         >
> >         > 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.
> >
> >
> > Raj> Okay.
> >
> >         >
> >         >
> >         > 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.
> >
> >
> > Raj> Can you point me to the new text that clarifies this?
>
> [Carlos] This is clarified in Section 5.2.3:
>
>    o  The local mobility anchor MUST advertise a connected route into
>       the Routing Infrastructure for the IP prefixes delegated to all of
>       the mobile routers that it is serving.  This step essentially
>       enables the local mobility anchor to be a routing anchor for those
>       IP prefixes and be able to intercept IP packets sent to those
>       mobile networks.
>
> >
> > -Raj
> >
> >         >
> >         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
> >
> >
> >         _______________________________________________
> >         netext mailing list
> >         netext@ietf.org
> >         https://www.ietf.org/mailman/listinfo/netext
> >
> >
> >
> >
> >
> > --
> > Basavaraj Patil
>
>
>


-- 
Basavaraj Patil