Subject: [netext] AD review of draft-ietf-netext-pmip-lr

From: Jari Arkko <[email-masked]>
Date: Fri, 25 Nov 2011 09:24:38 -0900

I have reviewed this draft.

It is in good shape and almost ready to move forward. I did find a couple of issues, however, and the most serious one of these is the one about tear-down. Please fix this and submit a new draft so that I can initiate an IETF last call.

>     If a MAG is unable to deliver packets using the LREs, it is possible
>     that the MN is no longer attached to the MAG.  Hence, the MAG SHOULD
>     fall back to using the BUL entry, and the LMA MUST forward the
>     received packets using its BCE.
>

This seems wrong. First of all, there are two MNs. Maybe you should say "... that one of the MNs is no longer ...". Secondly, since you had a MUST earlier for use of the LRE, shouldn't the SHOULD be a MUST too?

>     If one of the MNs, say MN1, detaches from the MAG and attaches to
>     another MAG (say nMAG) the localized routing state needs to be re-
>     established.  When the LMA receives the PBU from nMAG for MN1, it
>     will see that localized routing is active for MN1.  It will hence
>     initiate LR at nMAG and update the LR state of MAG.  After the
>     handover completes, the localized routing will resemble Scenario A21.
>

I think you should explain how the state in the pMAG changes. I presume this is just standard RFC 5213 behaviour, but nevertheless it is important for the pMAG to know that it should no longer do RO.

> When a supported
>     scenario, such as Scenario A12, morphs into Scenario A22 the node
>     that initiated the localized routing session SHOULD tear it down in
>     order to prevent lasting packet loss.

Shouldn't this be a MUST?

> The node
>     that initiated the localized routing session SHOULD tear it down in
>     order to prevent lasting packet loss.
> In
>     deployments where Scenario A22 is possible, it is recommended that
>     localized routing not be initiated when packet-loss-sensitive
>     applications are in use.

There are *no* situations where lasting packet loss is acceptable. So I think you have to handle this. I don't mean that you have to be able to use RO in A22, but you have to be able to tear RO down when the situation changes.

I think this is doable, and a part of the tear-down in general happens. When the device that initiated RO realizes that one of the involved sessions is gone elsewhere, it MUST do a RLI with lifetime 0 to tear the session down in the other nodes.

>     PMIPv6 MNs can use an IPv4 HoA as described in [RFC5844  <http://tools.ietf.org/html/rfc5844>].  In order
>     to support the setup and maintenance of localized routes for these
>     IPv4 HoAs in PMIPv6, MAGs must add the IPv4 HoAs into their LREs.
>     The MAGs MUST also support encapsulation of IPv4 packets as described
>     in [RFC5844  <http://tools.ietf.org/html/rfc5844>].  The localized routing protocol messages MUST include a
>     IPv4 HoA option in their signaling messages in order to support IPv4
>     addresses for localized routing.
>
>     ...
>
>     Note that this document supports LR only for IPv6 traffic, and LR is
>     not supported for IPv4 traffic.

The last paragraph seems inconsistent with the first paragraph. Remove one of them?

>     All the Localized routing messages use a new mobility header type
>     (TBA1).
>     The Localized Routing Initiation, described inSection 9.1  <http://tools.ietf.org/html/draft-ietf-netext-pmip-lr-07#section-9.1>  and the
>     Localized Routing Acknowledgment, described inSection 9.2  <http://tools.ietf.org/html/draft-ietf-netext-pmip-lr-07#section-9.2>  require a
>     single Mobility Header Type (TBA1) from the Mobility Header Types
>     registry athttp://www.iana.org/assignments/mobility-parameters
>

This seems odd. Usually, a message and its acknowledgment have different message types. TBA1 and TBA2... I can see that you have the R flag, but this isn't the usual way to define new MH messages.

>        Mobility Options: MUST contain the MN-ID, followed by one or more
>        HNPs for each of the MNs.  For instance, for Mobile Nodes MN1 and
>        MN2 with identifiers MN1-ID, MN2-ID and Home Network Prefixes
>        MN1-HNP and MN2-HNP, the following tuple in the following order
>        MUST be present: [MN1-ID, MN1-HNP], [MN2-ID, MN2-HNP].  The
>        MN-ID and HNP options are the same as in [RFC5213  <http://tools.ietf.org/html/rfc5213>].  MAY contain
>        the remote MAG IPv6 address option, which is formatted identically
>        to the HNP option, except that it uses a different Type code and
>        the Prefix Length is always equal to 128 bits (seeSection 10.1  <http://tools.ietf.org/html/draft-ietf-netext-pmip-lr-07#section-10.1>).
>

I think you could explain this better. My understanding is that there is only one option for MN-ID, so by repeating that option you will signal two identities.

"MUST contain two separate MN-iD options, followed by ..."

And you should define which one is which. The first one is the one that is always in the MAG that sends/receives the message?

>
>     11. Security Considerations
>
>
>
>     The protocol specified in this document uses the same security
>     association as defined in [RFC5213  <http://tools.ietf.org/html/rfc5213>] for use between the LMA and the
>     MAG to protect the LRI and LRA messages.  This document also assumes
>     the pre-existence of a MAG-MAG security association if LR needs to be
>     supported between them.  No new security risks are identified as
>     compared to [RFC5213  <http://tools.ietf.org/html/rfc5213>].  Support for integrity protection using IPsec
>     is required, but support for confidentiality is not necessary.
>

I think you should highlight one new risk, which is the risk of setting up a MAG-MAG tunnel. The document should also specify what packets are allowable to come from such tunnels (to prevent spoofing attempts).

>     12. IANA Considerations

What is the situation with the LRA Status field? Does it need its own registry, or are the values shared between PBA status values?

Please specify.

>    == The document seems to lack the recommended RFC 2119 boilerplate, even if
>       it appears to use RFC 2119 keywords -- however, there's a paragraph with
>       a matching beginning. Boilerplate error?

Please see if you can fix this idnits warning. Some wording difference between Section 3 and what 2119 uses, perhaps?

Jari