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

[Basavaraj Patil <[e-mail]>]

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 <
[e-mail]> 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
> > <[e-mail]> 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
> >         > [e-mail]
> >         > https://www.ietf.org/mailman/listinfo/netext
> >
> >
> >         _______________________________________________
> >         netext mailing list
> >         [e-mail]
> >         https://www.ietf.org/mailman/listinfo/netext
> >
> >
> >
> >
> >
> > --
> > Basavaraj Patil
>
>
>


-- 
Basavaraj Patil