Prefix Delegation Support for Proxy Mobile IPv6
draft-ietf-netext-pd-pmip-14

cleared my discuss having had it addressed.

was:

From the ops-dir review

I don't see these as blockers but I'd like to seem some dicussion on them, thanks.

...
However, the document doesn't provide much guidance in general in terms of logging/reporting. For e.g., in Section 5.1.2 Signaling Considerations - Is there a mechanism to inform the mobile router with some status in the event that the MAG receives a REQUESTED_DMNP_IN_USE or NOT_AUTHORIZED_FOR_DELEGATED_MNP message?
...
Also, in some cases  it is not clear if packets should be silently discarded (e.g. section 5.1.4 Packet Forwarding) or logged and discarded. I'd imagine that the latter might be beneficial from an operational point of view. Not sure if there was any discussion regarding this.
...

I'd like to be able to use an MR that can do this, so 
thanks for working on this.

I expected to see a security consideration to the effect
that there could be DoS issues e.g. for the LMA caused
by a large set of LFNs being behind an MR. Doesn't
something like that warrant a mention?

In Section 1, paragraph 1, this isn't a complete sentence:

   In this context, the mobility management support that
   is enabled for an individual IP host, which is the mobile node.

I don't know what was intended here, but please figure it out and fix it. :)

The use of the term "mobile network" to mean the network that is moving around is _really_ confusing. I get why you chose this terminology, but every time I see "mobile network" I think of the upstream network, rather than the downstream network.

In 3.2.1:
   The Advertise and Request messages are optional, and they
   are not used if a two message client-server exchange is used.

This is a really vague way of saying something that is sort of true.   The right way to say this is:
   If the requesting router includes a Rapid Commit option in its
   Solicit message, it is preferable that the MAG respond directly
   with a Reply rather than with an Advertise message, as described
   in RFC 3315, Section 17.2.3.

In 3.2.2 paragraph 2, the relay agent behavior is described in RFC 3315, not RFC 3633.

In 4.1, given that at least 8 of the sixteen bits of the DMNP are going to be zero, wouldn't it make sense to only include the bits that are included in the prefix length, and default the rest to zero?

In 5.1.3.1:

   o  In case the Proxy Binding Update signaling with the local mobility
      anchor is not completed successfully, for example because the
      local mobility anchor is not authorized for delegated mobile
      network prefix or the requested prefix is in use, the DHCPv6
      Delegating Router will send a Reply message to the Requesting
      Router containing the IA_PD with the lifetimes of the prefixes in
      the IA_PD set to zero.

This text only makes sense after the MR has successfully gotten a prefix delegation.   Before that, there won't be any prefixes in the IA_PD.   You would do better to just defer to RFC 3633:

   o  In case the Proxy Binding Update signaling with the local mobility
      anchor is not completed successfully, for example because the
      local mobility anchor is not authorized for delegated mobile
      network prefix or the requested prefix is in use, the DHCPv6
      Delegating Router will send a Reply message to the Requesting
      Router with no IA_PREFIX suboptions and with a Status Code
      option as described in RFC 3633, section 11.2.

The same advice applies to the equivalent paragraph in 5.1.3.2.

Next paragraph:

   The standard DHCPv6 considerations will be applied with respect to
   the interactions between the Delegating Router and the Requesting
   Router.  The Delegating Router is provided with the delegated
   prefix(es), which can then be then advertised in the mobile network,
   and therefore used by the locally fixed nodes to auto configure IP
   addresses allowing to gain access to the Internet.

The last sentence should probably start with "The Requesting Router," since it's the requesting router that's in the MR, not the delegating router.

Former DISCUSS:

DISCUSS item 1:

In 3.2.2, paragraph 2, the text doesn't really describe what's happening in the diagram. Not only is this a usability issue for vision-challenged readers, you're glossing over some very weird behavior here.   I would suggest the following change:
OLD:
   Once the mobile access gateway gets the set of
   delegated prefixes from the delegating router function running on the
   local mobility anchor, it conveys it in a proxy binding update.  This
   ensures that the local mobility anchor properly routes the traffic
   addressed to the delegated prefixes via the PMIPv6 tunnel established
   with the mobile access gateway, and that mobility is provided to
   these prefixes while the mobile router roams within the PMIPv6
   domain.
NEW:
   If the client did not request Rapid Commit, or the LMA doesn't
   support it, the relay agent on the MAG will behave normally in
   accordance with RFC 3315 in handling the Advertise message
   from the DR and the Request message from the RR.   However,
   the MAG does not strictly follow RFC3315 in its handling of the
   Reply message.

   When the MAG receives the DHCPv6 Reply message from the
   LMA, it extracts the DMNP from the Reply message and
   sends a PBU to the LMA containing the DMNP from the
   Reply message.   When the PBA comes back from the
   LMA containing the DMNP, the Reply message is forwarded
   to the client.

I realize that the intention here was to gloss over this and leave it for the interworking stuff that isn't specified in this document, but what you are doing to the relay function in the MAG here is sufficiently weird that I think you need to call it out explicitly.


You can resolve this DISCUSS item by making the change I've proposed above, or explaining why that's not the right thing to do.

I am also concerned that you haven't accounted for any of the things that can go awry during this process, but I am reluctant to demand that you fully flesh out the interworking, and that is what you would have to do to address this problem.   You do not need to address this point to clear the DISCUSS, but I'm mentioning it here because it concerns me and is related to the first DISCUSS item.

DISCUSS item 2:

I'm noticing in 5.1.3.2 that you are talking about IPv4 prefixes, but of course RFC3633 does not support IPv4 prefixes.   What's the intention here?   To resolve this DISCUSS item you need to explain what was intended here and possibly negotiate a fix.

DISCUSS item 3:

You never talk about how the identity of the MR that is presented over DHCPv6 will be correlated with the identity of the MR that is presented over PMIPv6.   This seems like an important detail.   Have you thought about it?   Why isn't it described here?   To resolve this DISCUSS item, you need to answer these questions and possibly add some text, with which I will be happy to help.