Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2014-03-25
07 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-03-13
07 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-02-07
07 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-01-17
07 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2014-01-17
07 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2014-01-16
07 (System) IANA Action state changed to Waiting on Authors from In Progress
2014-01-13
07 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent
2014-01-13
07 (System) RFC Editor state changed to EDIT
2014-01-13
07 (System) Announcement was received by RFC Editor
2014-01-11
07 (System) IANA Action state changed to In Progress
2014-01-10
07 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent
2014-01-10
07 Amy Vezza IESG has approved the document
2014-01-10
07 Amy Vezza Closed "Approve" ballot
2014-01-10
07 Amy Vezza State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2014-01-10
07 Brian Haberman Ballot writeup was changed
2014-01-10
07 Brian Haberman Ballot approval text was generated
2014-01-09
07 Ted Lemon
[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 …
[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.
2014-01-09
07 Ted Lemon [Ballot Position Update] Position for Ted Lemon has been changed to No Objection from Discuss
2014-01-01
07 Sean Turner [Ballot comment]
Thanks for adding some text to address the sequence number.

Happy New Year!
2014-01-01
07 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2013-12-26
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-12-26
07 Luis Contreras IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2013-12-26
07 Luis Contreras New version available: draft-ietf-multimob-handover-optimization-07.txt
2013-12-18
06 Gunter Van de Velde Closed request for Telechat review by OPSDIR with state 'No Response'
2013-12-05
06 Cindy Morgan State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2013-12-05
06 Barry Leiba
[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 …
[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.
2013-12-05
06 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2013-12-05
06 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-12-05
06 Stephen Farrell
[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 …
[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.
2013-12-05
06 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2013-12-05
06 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2013-12-05
06 Sean Turner [Ballot discuss]
This might be quick....

The sequence number are all 8 bits.  Is that enough?  Don't you need a sequence number wrap procedure?
2013-12-05
06 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner
2013-12-04
06 Joel Jaeggli
[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 …
[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.
2013-12-04
06 Joel Jaeggli Ballot comment text updated for Joel Jaeggli
2013-12-04
06 Barry Leiba
[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, …
[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.
2013-12-04
06 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2013-12-04
06 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2013-12-03
06 Scott Brim Request for Telechat review by GENART Completed: Ready. Reviewer: Scott Brim.
2013-12-03
06 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2013-12-02
06 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2013-12-01
06 Ted Lemon
[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 …
[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.
2013-12-01
06 Ted Lemon Ballot discuss text updated for Ted Lemon
2013-12-01
06 Ted Lemon
[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 …
[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.  :)
2013-12-01
06 Ted Lemon [Ballot Position Update] New position, Discuss, has been recorded for Ted Lemon
2013-11-30
06 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2013-11-27
06 Jean Mahoney Request for Telechat review by GENART is assigned to Scott Brim
2013-11-27
06 Jean Mahoney Request for Telechat review by GENART is assigned to Scott Brim
2013-11-15
06 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Victor Fajardo
2013-11-15
06 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Victor Fajardo
2013-11-12
06 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2013-11-11
06 Brian Haberman Ballot has been issued
2013-11-11
06 Brian Haberman [Ballot Position Update] New position, Yes, has been recorded for Brian Haberman
2013-11-11
06 Brian Haberman Created "Approve" ballot
2013-11-11
06 Brian Haberman State changed to IESG Evaluation from Waiting for Writeup
2013-11-11
06 Brian Haberman Placed on agenda for telechat - 2013-12-05
2013-11-11
06 Brian Haberman Ballot writeup was changed
2013-11-07
06 Carlos Jesús Bernardos IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2013-11-07
06 Carlos Jesús Bernardos New version available: draft-ietf-multimob-handover-optimization-06.txt
2013-11-05
05 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Chris Lonvick.
2013-11-01
05 (System) State changed to Waiting for Writeup from In Last Call (ends 2013-11-01)
2013-10-30
05 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2013-10-30
05 Amanda Baber
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 …
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.
2013-10-24
05 Jean Mahoney Request for Last Call review by GENART is assigned to Scott Brim
2013-10-24
05 Jean Mahoney Request for Last Call review by GENART is assigned to Scott Brim
2013-10-24
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Chris Lonvick
2013-10-24
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Chris Lonvick
2013-10-18
05 Amy Vezza IANA Review state changed to IANA - Review Needed
2013-10-18
05 Amy Vezza
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 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.


2013-10-18
05 Amy Vezza State changed to In Last Call from Last Call Requested
2013-10-18
05 Brian Haberman Last call was requested
2013-10-18
05 Brian Haberman Last call announcement was generated
2013-10-18
05 Brian Haberman Ballot approval text was generated
2013-10-18
05 Brian Haberman Ballot writeup was generated
2013-10-18
05 Brian Haberman State changed to Last Call Requested from AD Evaluation::AD Followup
2013-10-18
05 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-10-18
05 Carlos Jesús Bernardos New version available: draft-ietf-multimob-handover-optimization-05.txt
2013-10-17
04 Brian Haberman State changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2013-10-17
04 Brian Haberman
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 …
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 3810RFC 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
2013-10-07
04 Brian Haberman State changed to AD Evaluation from Publication Requested
2013-10-04
04 Behcet Sarikaya IETF WG state changed to Submitted to IESG for Publication
2013-10-04
04 Behcet Sarikaya IESG state changed to Publication Requested
2013-10-04
04 Behcet Sarikaya State Change Notice email list changed to multimob-chairs@tools.ietf.org, draft-ietf-multimob-handover-optimization@tools.ietf.org
2013-10-04
04 Behcet Sarikaya Responsible AD changed to Brian Haberman
2013-10-04
04 Behcet Sarikaya Working group state set to Submitted to IESG for Publication
2013-10-04
04 Behcet Sarikaya IESG state set to Publication Requested
2013-10-04
04 Behcet Sarikaya IESG process started in state Publication Requested
2013-10-04
04 Behcet Sarikaya Changed consensus to Yes from Unknown
2013-10-04
04 Behcet Sarikaya Intended Status changed to Experimental from None
2013-10-04
04 Behcet Sarikaya Changed document writeup
2013-10-04
04 Behcet Sarikaya Document shepherd changed to Behcet Sarikaya
2013-09-11
04 Luis Contreras New version available: draft-ietf-multimob-handover-optimization-04.txt
2013-07-08
03 Luis Contreras New version available: draft-ietf-multimob-handover-optimization-03.txt
2013-02-25
02 Luis Contreras New version available: draft-ietf-multimob-handover-optimization-02.txt
2012-12-31
01 Luis Contreras New version available: draft-ietf-multimob-handover-optimization-01.txt
2012-11-29
00 Carlos Jesús Bernardos New version available: draft-ietf-multimob-handover-optimization-00.txt