Subject: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01

From: <[email-masked]>
Date: Mon, 7 Nov 2011 20:17:52 +0000

A few quick comments:

1. Abstract should have no references. And the description can be
   improved. It really is hard to understand what this I-D is trying
   to accomplish. 

2. The introduction section can be improved. Maybe you should include
   a problem statement section to indicate what is lacking in PMIP6 as
   per RFC5213.

3. In Sec 3.1 it states:
"
   o  The MR (as a RR) MUST either obtain the Home Network Prefix (HNP)
      before initiating the DHCPv6-PD procedure or in case of stateful
      address configuration simultaneously while configuring the Mobile
      Node Home Address (MN-HoA).
"

   So does this imply that the MR (PMIP6 MN) obtains an HNP as per
   RFC5213 for its own use prior to the MR requesting via DHCPv6
   another set of prefixes to be used for delegating to downstream
   nodes? 

4. If the prefixes (delegated) are provided by a DHCP server (and not
   the LMA), how does the LMA get informed about these? In the PBU?
   How do you ensure that
   "All the mobile network prefixes managed in the DR MUST be
   reachable via local mobility anchor (LMA)" when they are not
   assigned by the LMA?

5. Sec 3.1 also states:
   "The delegating router (DR) can be located either at LMA or some
      other device in the PMIPv6 domain"

    What is this some other device?

6.  In Sec 3.2 the I-D states that the profile needs to indicate
    whether an MN can be assigned prefixes for delegation. Does the
    profile indicate whether the host is a mobile router? Is this
    needed? Any MN should be able to act as an MR.

7. In Fig 1, you have a DR shown there. How does the DR indicate the
   assigned prefixes to the LMA?
   - Step 5 seems disconnected from the rest of the process. Maybe it
   is better to split that aspect and show it in another figure.

8. Does the lifetime of the delegated prefix (assigned by a DR) the
   same as the lifetime assigned by the LMA?
   Why not have Sec 3.3.3 to describe how a prefix is revoked or
   deleted? Text is currently in 3.3.2.

9. In sec 3.4.2:
   "Other considerations from Section 6.10.5 or [RFC5213]"

   Sec 6.10.5 of this I-D? There is none.

10. Sec 3.5.2 states:
    "In order to receive
      those packets, the LMA MUST advertise a connected route into the
      routing infrastructure for the MR's MNP(s)."

    - Is it enough from a specification standpoint to state that the
      routes need to be injected into the routing infra?
      Handwaving????

11. Are there any new threats or security issues that arise from
    assigning prefixes to be delegated downstream in the case of
    PMIP6? Security section seems pretty light.

-Raj

---

From: [email-masked]
Date: Thu, 10 Nov 2011 20:30:57 +0800

Hi Raj,
Thanks for your comments. Please see below inline.

>    a problem statement section to indicate what is lacking in PMIP6 as
[Joy]Rewording will be done for 1&2 in next version.
>    another set of prefixes to be used for delegating to downstream
[Joy]Yes.
>    reachable via local mobility anchor (LMA)" when they are not
[Joy]Here it assumes that the LMA can interact with the DHCPv6 Server 
within some other mechanisms e.g. Radius.
>     What is this some other device?
[Joy]Here we just study these two kinds of deployments which are common in 
current network.
>     needed? Any MN should be able to act as an MR.
[Joy]MN is able to act as an MR does not mean it can obtain mobile network 
prefix. Usually whether the mobile network prefix is allowed depends on 
the profile.
>    is better to split that aspect and show it in another figure.
[Joy]As I say in Q4. I am not sure what you mention of the step 5. It is 
just relayed by the MAG.
>    same as the lifetime assigned by the LMA?
[Joy]Yes.
>    deleted? Text is currently in 3.3.2.
[Joy]This is a good proposal.
>    Sec 6.10.5 of this I-D? There is none.
[Joy]It does exist "6.10.5.  Forwarding Rules"
>       routes need to be injected into the routing infra?
[Joy]From the routing perspective, I am not sure what else needs to be 
specified. Can you give another proposal?
>     PMIP6? Security section seems pretty light.
[Joy]We will search for possible text for this in the future discussion.

Joy
> 
> 
> -Raj
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>

---

From: jouni korhonen <[email-masked]>
Date: Thu, 10 Nov 2011 22:21:07 +0200

Raj,

On Nov 10, 2011, at 2:30 PM, [email-masked] wrote:

> [Joy]Here it assumes that the LMA can interact with the DHCPv6 Server within some other mechanisms e.g. Radius.

The situation is the same as with PMIP6 and DHCPv6 in general. The DHCPv6 server and the LMA has to be in sync. There is no need for an interface as everything can be managed with configuration. But that does not preclude having an interface between the LMA and the DHCPv6 server.

- Jouni

---

From: <[email-masked]>
Date: Thu, 10 Nov 2011 20:29:59 +0000

Inline:

On 11/10/11 2:21 PM, "ext jouni korhonen" <[email-masked]> wrote:

>The situation is the same as with PMIP6 and DHCPv6 in general. The DHCPv6
>server and the LMA has to be in sync. There is no need for an interface
>as everything can be managed with configuration. But that does not
>preclude having an interface between the LMA and the DHCPv6 server.

How do you keep the DHCPv6 server and the LMA in sync? Is it considered
out-of-scope and the actual method about how they are synced not
specified? If the DHCPv6 server and LMA are co-located, it could be
easier. If they are not, then it may be an issue. The argument that you
can use a Radius type interface between DHCPv6 server and the LMA is not
good enough. Is there such a specification? The Netext WG has only
specified the RADIUS interactions between a AAA server and the MAG/LMA
entities.

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 10 Nov 2011 12:36:10 -0700

I agree. I think we should simply assume the DHCPv6 server and the LMA are
collocated. For the split case, we loosely specify the assumptions and the
interface should be out of scope.

Sri

---

From: <[email-masked]>
Date: Thu, 10 Nov 2011 20:44:39 +0000

Inline:

> [Joy]Rewording will be done for 1&2 in next version.

Good.

> >    another set of prefixes to be used for delegating to downstream

Some text clarifying this would be useful in the document.

> [Joy]Here it assumes that the LMA can interact with the DHCPv6 Server within some other mechanisms e.g. Radius.

This is an assumption. See my response to Jouni.

> [Joy]Here we just study these two kinds of deployments which are common in current network.

You mean the some other device is the LMA? What is this "some other device" that you refer to in the text.
And what are these two kinds of deployments. Your response did not provide an answer here.

> [Joy]MN is able to act as an MR does not mean it can obtain mobile network prefix. Usually whether the mobile network prefix is allowed depends on the profile.

Agree. But an MN can also behave as a MR. Whether it can be allocated prefixes for delegation depends on the profile. So my point is that the text should not differentiate between an MN and MR.

> [Joy]As I say in Q4. I am not sure what you mention of the step 5. It is just relayed by the MAG.

Lets discuss at the WG meeting next week.

> >    same as the lifetime assigned by the LMA? 

How do you ensure it if the delegated prefixes are assigned by the DHCPv6 server and the LMA chooses to assign a different lifetime in the PBA.

> [Joy]It does exist "6.10.5.  Forwarding Rules"

Change the Or to Of in the sentence. That is the problem. 

> [Joy]From the routing perspective, I am not sure what else needs to be specified. Can you give another proposal?

My point here is that is it possible to implement this extension and deploy the protocol based on just this explanation about what needs to be done by the LMA w.r.t the routing infra?

> [Joy]We will search for possible text for this in the future discussion. 

Good.

Thx.
-Raj

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 10 Nov 2011 16:46:28 -0600

Hi Basavaraj,

I have a question:

Can we at Netext work on specs that require modifying MN?

Reading the charter:

The work in this charter is entirely internal to the network and does
  not affect host IP stack operation in any way (except perhaps through
  impacting packet forwarding capacity visible to the hosts).

It seems to me the answer is no?

Regards,

Behcet

---

From: <[email-masked]>
Date: Mon, 14 Nov 2011 01:38:06 +0000

Behect,

I believe you answered your own question in the email. So yes, you are correct. The answer is No.

-Basavaraj

From: ext Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>
Reply-To: Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>
Date: Thu, 10 Nov 2011 16:46:28 -0600
To: Basavaraj Patil <[email-masked]<mailto:[email-masked]>>
Cc: Netext <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01

Hi Basavaraj,

I have a question:

Reading the charter:

Regards,

Behcet
On Mon, Nov 7, 2011 at 2:17 PM, <[email-masked]<mailto:[email-masked]>> wrote:

A few quick comments:

3. In Sec 3.1 it states:
"

5. Sec 3.1 also states:

9. In sec 3.4.2:

10. Sec 3.5.2 states:
   "In order to receive

-Raj

_______________________________________________
netext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netext