Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey
draft-irtf-mobopts-mmcastv6-ps-09

I have today reviewed this document. The purpose of my review and the following IESG review is to perform a so called RFC 3932 check, i.e., make sure that documents outside the IETF stream do not allocate IANA values reserved for standards track protocols or otherwise collide with IETF working group efforts.

I have not found any collision with this work and IETF work, though obviously, this work has been one of the inputs for the formation of the MOBOPTS working group, and also talks about IP over a number of link layers.

I have recommended the standard RFC 3932 boilerplate IESG note about non-IETF work. Once the 3932bis work is concluded we will be able to make use of the new style of headers and boilerplates which do not require IESG notes. I have written to the tracker that if this happens before this document comes out of the RFC Editor queue then no note is needed.

The document will be under the entire IESG's review in two weeks to confirm my recommendation. Please remember that neither my review or the IESG review is a technical review. In other words, the RG is fully responsible for the correctness of the document. As a personal note I wanted to say nevertheless that I was reasonably happy with the document. Thank you for writing this.

In any case, I have included a few personal review comments below. Also, as the document contains quite a bit of material relating to IP over 802.16 and IP over DVB, I have Cced the relevant working group chairs in case they have further comments.

Jari Arkko

> obility management may issue
>    traffic directives that lead to suboptimal routing, i.e., erroneous
>    subscriptions following predictive handover operations, or slow
>    effective leaves caused by MLD querying, or by departure of the MN
>    from a previous network without leaving the subscribed groups.

I had a hard time parsing this. Maybe say instead: "Mobility management may impact routing by, e.g., erroneous ... or by MNs leaving networks without unsubscribing form the groups they were receiving.". What's a "slow effective leave"?

> IP multicast deployment in general has been hesitant over the past 15
>    years

s/hesitant/slow/?

> a strong business case for IP
>    portables
... portable IP-based devices.

> Current packet filtering practice causes inter-working problems between Mobile IPv6 nodes connected via GPRS [46].
This is incorrect AFAIK. There are filtering procedures in IMS that cause problems for Mobile IPv6 and other things. However, those filtering mechanisms are not a part of the link layer nor are they applied for regular Internet access. I would suggest this statement be deleted from the draft, along with the reference.

> PTM uses an
>    unidirectional common channel, operating in unacknowledged without
>    adjustment of power levels and no reporting on lost packets.

... unacknowledged mode?

>  Mobility services transport for MIH naturally reside
>    on the network layer and are currently in the process of
>    specification [55].
>
draft-ietf-mipshop-mstp-solution is an approved specification (though not yet out of the RFC Ed queue).

Also, I believe 802.21 specifies both network and link layer transport, so its not clear why you say "naturally" above.

In general Section 4 wanders off a little bit to topics outside multicast. I understand that some amount of explanation is needed about what each L2 technology does, but I'd consider tightening the text in AUTH48 in some places.

> MLD
>    router querying will allow the multicast forwarding state to be
>    restored in case of an erroneous prediction (i.e., an anticipated
>    move to a network that is not fulfilled).
fulfilled?

>    Mobility protocols need to consider the implications and requirements
>    for AAA. AAA binding records may change between attachments, or may
>    be individually chosen prior to network (re-)association. The most
>    appropriate network path may be one that satisfies user preferences,
>    e.g., to use/avoid a specific network, minimize monetary cost, etc,
>    rather than one that only minimizes the routing cost. Consequently,
>    AAA bindings cannot be treated at a pure level of context transfer.
It was not clear to me why AAA is relevant. And what's an "AAA binding record"? I must say that I don't understand the rest of the paragraph either.

The term AAA was not defined or expanded. Please check the other terms too.

> Due to lack of feedback, the admission [83] and binding
>    updates [84] of mobile multicast sources require autonomously
>    verifiable authentication as can be achieved by Cryptographically
>    Generated Addresses (CGAs).
And presumably with other means as well. I would suggest saying "... be achieved by, for instance, ...".

It would have been interesting if Section 8 listed some of the multicast specific issues around security. For instance, I would presume that a HA operating tunneled multicast service by n-casting is more vulnerable to a DoS attack than some other more native multicast solution.

This is a request for the IESG to perform a RFC3932bis review of draft-irtf-mobopts-mmcastv6-ps-08.txt [1] to be published an an Informational IRTF RFC. The document has been approved for publication by the IRSG. See [2] for details on prior reviews. Please copy all correspondence to the document shepherd, Rajeev Koodli .

--aaron

[1] http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps
[2] http://trac.tools.ietf.org/group/irtf/trac/ticket/26