[netext] Review of draft-ietf-netext-pd-pmip-01.txt

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

Hi,

As promised in the last meeting, I've reviewed
draft-ietf-netext-pd-pmip-01.txt. Here are my comments:

- I think the goals of the document should be more clear, as 3 different
concepts are involved: DHCPv6 Prefix Delegation, Proxy Mobile IPv6 and
NEMO. Actually, I think this is not an easy problem to solve, because
the scenario described in the document is not really a NEMO one (I'll
explain this better below).

- The abstract says: "This document specifies an extension to Proxy
Mobile IPv6 protocol for supporting network mobility using DHCPv6-based
Prefix Delegation.". This is not very aligned with the title of the
document, which seems to suggest that the document just specifies how to
delegate prefixes using DHCPv6 in PMIPv6 (but in reality the document
does more than this).

- The abstract also says: "DHCPv6 Prefix Delegation can be used to
assign a prefix or prefixes to a mobile router for use on the links in
the mobile network as specified in [RFC6276] but not supported in Proxy
Mobile IPv6.". RFC6276 is for use with the Network Mobility Basic
Support protocol (RFC 3963), but the draft does not consider NEMO at
all, as what is called "Mobile Router" does not have any IP mobility
support at all. Therefore, any link between RC3963/RFC6275 and the draft
may lead to confusion, IMHO.

- In the Introduction (and in the rest of the document), the term Mobile
Router (MR) is used, though it is not accurate, as RFC3963 tends to
implicitly assume that an MR implements the NEMO BS protocol (e.g., "A
Mobile Router has a unique Home Address through which it is reachable
when it is registered with its Home Agent."). However, in the draft, it
is mentioned that "The specification assumes that a MR is a regular IPv6
router without extension for mobility managements.", so I think it's
better not to call this "router" MR.

- I'd rewrite the Introduction to make the problem scope clearer. I
needed to read the whole document to get the full picture (it was not
clear to me when I was reading the intro).

- I'd avoid using normative text (like MUST) in the intro.

- In Section 3.1, the document starts mixing the terms MN and MR, which
again, is a source of potential misunderstandings. For example, it says
"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)."

- I don't see why the MR should support the Prefix Exclude Option.

- In Section 3.2: "If the network mobility service needs to be offered
to the mobile node, the mobile access gateway MUST set the Mobile Router
Flag (R) when sending the Proxy Binding Update (PBU) message to the
LMA.". I think this cannot be done, as RFC3963 states that "The Mobile
Router Flag is set to indicate to the Home Agent that the Binding Update
is from a Mobile Router.". Therefore, if the "R" bit is set, that means
that the (P)BU is sent by an MR implementing RFC3963 (which is not the
case here), unless this draft is updating RFC3963.

- In Section 3.3.1, the terms "MN" and "MR" are again mixed, which makes
it complex to follow.

- Another, IMHO, source of potential misleading, is the use of the MNP
option, which again is tightly related to the RFC3963. Not sure if it'd
be good to define a new option for this. For example, the HNP and MNP
options are exactly the same format-wise, but we have two different
options (types) because it is better not to overload too much them.

- In Section 3.4.2, it says: "On receiving a packet from the
bi-directional tunnel established with the MR's LMA, the MAG MUST use
the destination address of the inner packet to forward it on the
interface where the destination MNP is hosted." --> does this mean that
the packet is not decapsulated and then routed, but routed based on the
inner packet destination address? If so, this seems very weird to me. I
guess the tunnel ends at the MAG, like in regular PMIPv6 for a host. In
that case, I'd say that some additional text about forwarding
considerations on the MAG is missing (e.g., the MAG has to add a route
for the "MNP" via the "MR").

- In Section 3.5.2, it says: "In order to receive those packets, the LMA
MUST advertise a connected route into the routing infrastructure for the
MR's MNP(s).". I guess the "advertisement" is not really mandatory (no
need of using MUST there), as what is required is that the LMA anchores
the prefix, right?

- I'd say that the Security Considerations section may benefit from
additional text. I have not thought of that carefully, but at least some
examples of the SPD and SAD entries used to protect the signaling could
be helpful (e.g., as used in RFC6276).

This is just a first batch of comments. I think the document needs an
update and further revisions. Regarding the document's scope, I think
it's very important to make it clear. For example, as it is now, a rader
could think that this document addresses the problem I tried to describe
in draft-bernardos-netext-pmipv6-nemo-ps-01, but this is not the case.
While writing that draft I learned/suffered myself how difficult is to
clearly explain the problem.

In case it is not clear, I'm supportive of the problem described in
draft-ietf-netext-pd-pmip-01. I'm just trying to help here, so don't
take my comments as negative ones.

Thanks,

Carlos

-- 
Carlos Jesús Bernardos Cano  http://www.netcom.it.uc3m.es/
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67