Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL)
draft-ietf-multimob-handover-optimization-07

[Ballot comment]
Former DISCUSS, which I have cleared:

How does the LMA decide whether to follow the procedure illustrated by Figure 3 rather than the procedure illustrated by Figure 4?  Why not always follow the procedure shown in Figure 4?

This seems like kind of a big deal, since any buffering of TCP flows will result in unfortunate behavior on the part of TCP congestion-avoidance.  Indeed, why not do the procedure described in Figure 4 but without any PBA Timer—just send the PBA immediately and handle the multicast updates with a Subscr Query/Subscr Resp exchange in the reactive handover case?  I realize that this adds latency in theory, but in practice I would expect the request going to the pMAG to get a response in the same rough timeframe as the query coming back from the nMAG, meaning that in practice the Subscr Resp from the LMA to the nMAG would go out at roughly the same time that the delayed PBA would have.

[Ballot comment]
I understand there are two implementations in the works, and an interop test planned.  That satisfies my concern, my DISCUSS is cleared, and I hope the experiment is a raging success.  Thanks.

[Ballot comment]

Are you missing a (minor) security consideration?  The new
subscription query message does expose a little more
information to the LMA when the MN roams from the pMAG,
that is, the set of MC groups to which the MN is
subscribed. If the MN took the hit of a delay then I guess
only the pMAG and nMAG would know about the current MC
groups and the LMA might not.  If that's correct, then a
nasty LMA could use that to track the MC groups to which a
MN subscribes. I think that's perhaps worth noting, but am
not suggesting you do more than that.

[Ballot comment]
watching barry's dicsuss with interest.

The number of LMA/MAG implementors is not that large and they are participants, so if there's really not inkling of implementation then it's just a suggested optimization.

[Ballot discuss]
This is a well written, clear document, and I have no issues with the document itself.  This DISCUSS is primarily for the IESG, though input from the shepherd, chairs, and editors would help:

The shepherd writeup says, "There is a strong consensus behind this solution."  And yet it also says that it's Experimental *because* there are no implementations, and the writeup makes no mention of any plans for implementations, though the template explicitly asks that question.

And so I have to ask the question: what is the strong consensus for?  Documenting this in an RFC that never gets implemented?  Or *is* there really a strong consensus to implement this and experiment with it?  I have no objection to publishing this as an experiment, if there's actually some commitment to try it (and then I'd like to see some commitment to report the results in some way, and perhaps to move this onto Standards Track if it works out as well as the document leads us to expect it will).  But I do have an objection to publishing it just to publish it, if it's going to be largely ignored.

[Ballot discuss]
How does the LMA decide whether to follow the procedure illustrated by Figure 3 rather than the procedure illustrated by Figure 4?  Why not always follow the procedure shown in Figure 4?

This seems like kind of a big deal, since any buffering of TCP flows will result in unfortunate behavior on the part of TCP congestion-avoidance.  Indeed, why not do the procedure described in Figure 4 but without any PBA Timer—just send the PBA immediately and handle the multicast updates with a Subscr Query/Subscr Resp exchange in the reactive handover case?  I realize that this adds latency in theory, but in practice I would expect the request going to the pMAG to get a response in the same rough timeframe as the query coming back from the nMAG, meaning that in practice the Subscr Resp from the LMA to the nMAG would go out at roughly the same time that the delayed PBA would have.

[Ballot discuss]
How does the LMA decide whether to follow the procedure illustrated by Figure 3 rather than the procedure illustrated by Figure 4?  Why not always follow the procedure shown in Figure 4?

This seems like kind of a big deal, since any buffering of TCP flows will result in unfortunate behavior on the part of TCP congestion-avoidance.  Indeed, why not do the procedure described in Figure 4 but without any PBA Timer—just send the PBA immediately and handle the multicast updates with an unsolicited Subscr Resp message in the reactive handover case?

I'm expecting that this DISCUSS will be resolved by someone pointing out why this can't work, but it could also be resolved by doing what I suggested.  :)

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-multimob-handover-optimization-05.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First, in the Mobility Header Types - for the MH Type field in the Mobility Header registry in the Mobile IPv6 page at

http://www.iana.org/assignments/mobility-parameters/

two new header types will be registered as follows:

Value: [ TDB-at-registration ]
Description: Subscription Query
Reference: [ RFC-to-be ]

Value: [ TDB-at-registration ]
Description: Subscription Response
Reference: [ RFC-to-be ]

Second, in the Mobility Options registry in the Mobile IPv6 parameters page at

http://www.iana.org/assignments/mobility-parameters/

two new mobility options will be registered as follows:

Value: [ TDB-at-registration ]
Description: Active Multicast Subscription IPv4 mobility option
Reference: [ RFC-to-be ]

Value: [ TDB-at-registration ]
Description: Active Multicast Subscription IPv6 mobility option
Reference: [ RFC-to-be ]

Third, in the Binding Update Flags registry in the Mobile IPv6 parameters page at

http://www.iana.org/assignments/mobility-parameters/

a new binding update flag will be registered as follows:

Flag: S
Value: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

Fourth, in the Binding Acknowledgment Flags registry in the Mobile IPv6 parameters page at

http://www.iana.org/assignments/mobility-parameters/

a new binding acknowledgment flag will be registered as follows:

Flag: S
Value: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

IANA understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (PMIPv6 multicast handover optimization by the Subscription Information Acquisition through the LMA (SIAL)) to Experimental RFC


The IESG has received a request from the Multicast Mobility WG (multimob)
to consider the following document:
- 'PMIPv6 multicast handover optimization by the Subscription Information
  Acquisition through the LMA (SIAL)'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-11-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies an experimental multicast handover
  optimization mechanism for Proxy Mobile IPv6 to accelerate the
  delivery of multicast traffic to mobile nodes after handovers.  The
  mechanism is based on speeding up the acquisition of mobile nodes'
  multicast context by the mobile access gateways.  To do that,
  extensions to the current Proxy Mobile IPv6 protocol are proposed.
  These extensions are not only applicable to the base solution for
  multicast support in Proxy Mobile IPv6, but they can also be applied
  to other solutions developed to avoid the tunnel convergence problem.
  Furthermore, these extensions are also independent of the role played
  by the mobile access gateway within the multicast network (either
  acting as multicast listener discovery proxy or multicast router).




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-multimob-handover-optimization/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-multimob-handover-optimization/ballot/


No IPR declarations have been submitted directly on this I-D.

All,
    I have completed my AD evaluation of
draft-ietf-multimob-handover-optimization and found it to be quite
readable.  Thank you.

    I have a few issues that I would like to see resolved prior to
requesting IETF Last Call for this document.  Feel free to discuss them
with me if clarifications are needed.

1. Introduction:

* In the 2nd paragraph, I don't see the benefit to referencing a draft
that has been expired for 3 years.  I would suggest dropping the reference.

* In the 3rd paragraph : s/can help mitigating/can help mitigate

* The last paragraph is not needed and can be deleted.

2. Several places in the beginning of the document, there are references
to RFC 2710 but not RFC 3810.  RFC 6224 uses both and section 4.1.1
explicitly discusses RFC 3810 (albeit indirectly as MLDv2).  I would
suggest referencing both, add 3810 to the Normative References, and
properly reference 3810 in the appropriate places in section 4.

3. The reference to draft-ietf-multimob-pmipv6-ropt can be updated to be
RFC 7028.

4. Section 1.1

* The 2nd requirement is not a protocol requirement and should be
deleted.  It is trying to mandate implementation/deployment behavior.

* The "on" in requirement 3 can be removed.

* Would it make sense to add an additional requirement that this
experimental approach not impact deployments of legacy implementations
of RFC 5213 and RFC 6224?

5. Section 4.1.2 : It would be clearer if the description of the message
formats that are borrowed from 2710 and 3810 refer to those formats by
the terms used in the RFC.  For example, the Multicast Membership
Context field should refer to (or be called) the Multicast Address
Record (from 3810).

6. Sections 4.3.1.2 and 4.3.2.2

* Why are the sequence numbers 8-bit fields?  The sequence fields in
other PMIPv6 messages are 16-bit.

* I would suggest adding references for the options allowed in these
messages (Mobile Node Identifier, Home Network Prefix, and Active
Multicast Subscription).


Regards,
Brian