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

[Alexandru Petrescu <[e-mail]>]

Le 28/02/2012 19:51, Carlos Jesús Bernardos Cano a écrit :
> 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.

I agree.

> - 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.

Hm, I tend to agree.  It is however a sign to me that people tend to
understand many different things by MR, and not just a MIP6/NEMOv6 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)."

MN is a very confusing term when used in the context of network mobility.

Contrary to the term "MR" (sometimes not MIP6 in some text), MN is more
often required to implement MIP.

Besides, MN is udnesrtood as a MH or a MR depending on context.

IMHO it is good to make this distinction clearer, to avoid
misunderstandings generated by MN being sometimes MH other times MR.

>
> - 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.

I fully agree.

I think that rather than (wrongly) reusing the R bit flag in (P)BU for
MNP then rather define a new flag - "Q" .

> - 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.

Maybe require a new Type, to be a Type within a PBU to mean MNP.

> - 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").

If necessary, a clearer description could be written about this.

The way the MAG forwards packets to MNP'ed LFNs depends on that
interface being ptp or shared, and on having added or not an entry with
respect to the link-local address of MR's egress interface.

> - 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?

To me this advertisement word is often difficult to understand.

Besides, a "connected" route is something on-link on Cisco and other
routers - LMA does not hold such route for MNP.  Maybe MAG, and only if
not ptp link.

Listening for comments,

Alex

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