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

[Carlos Jesús Bernardos Cano <[e-mail]>]

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