Heartbeat Mechanism for Proxy Mobile IPv6
draft-ietf-netlmm-pmipv6-heartbeat-07

[Ballot comment]
I am not going to perpetuate Dave's Discuss, but I am hugely surprised that the Abstract says:
  This document describes a heartbeat
  mechanism between the MAG and the LMA to detect failures quickly and
  take appropriate action.
While Section 3 says:
  The HEARTBEAT_INTERVAL SHOULD NOT be configured to a value less than
  30 seconds.
Everything is relative, but these two statements are contradictions in my book. Section 1 exacerbates the problem by reapeatedly using the word "quickly."

I would really appreciate it if you could change the Abstract and Introduction to give relative scale to "quick" by referencing other protocol actions that may be carried out or attempted in the non-detection window.

[Ballot discuss]
In section 3.2 there seems to be a requirement for non-volatile memory.  This seems out of
place in a protocol specification.  I would prefer to see the section rewritten to explain what
state needs to be preserved across restarts.  I am interested in discussing this briefly on the
call.  If there is sufficient precedent/support for imposing these kinds of constraints in protocol
specifications, I will clear on the call.

[Ballot comment]
This is a calear and well-written document that could benefit from a few clarifications.

1. I suppose that a future chartered work in this WG will add a management interface - MIB module or similar. It would be good to mention what information is configurable and may be important to be exposed for an operator: certainly configuration of the parameters described in Section 5, maybe notifications of the failuere and restarts detections, other?

3.  HEARTBEAT_INTERVAL

      This variable is used to set the time interval in seconds between
      two consecutive Heartbeat Request messages.  The default value is
      60 seconds.  It SHOULD NOT be set to less than 30 seconds.

Would not it make sense to define a high limit here as well?

3.  MISSING_HEARTBEATS_ALLOWED

      This variable indicates the maximum number of consecutive
      Heartbeat Request messages that a PMIPv6 node can miss before
      concluding that the peer PMIPv6 node is not reachable.  The
      default value for this variable is 3.

Should not rather be 'are not responded' than 'can miss'?

[Ballot comment]
In Section 3, paragraph 3:

  The HEARTBEAT_INTERVAL SHOULD NOT be configured to a value less than
  30 seconds.  Sending heartbeat messages too often may become an
  overhead on the path between the MAG and the LMA.  The
  HEARTBEAT_INTERVAL can be set to a much larger value on the LMA, if
  required, to reduce the burden of sending periodic heartbeat
  messages.

By omission, the last sentence implies that the HEARTBEAT_INTERVAL should not be set
to a much larger value on the MAG.  If there *are* reasons not to configure larger intervals
on the MAG that should be noted here...

[Ballot discuss]
I have reviewed draft-ietf-netlmm-pmipv6-heartbeat-05. Overall, the
document looks good, but there's one thing that should be fixed before
the document is approved:

The text about IPsec (in Section 6) says heartbeat messages are
protected the same way as BU/Back in RFC 4877. But PMIPv6 itself does
not use the RFC 4877 approach to IPsec -- the PMIPv6-IPsec interaction
is much simpler, and is described in RFC 5213. Changing the text to
say "the same way as BU/BAck in RFC 5213" should be sufficient.

[Ballot comment]
Supports Lars Eggert's Discuss.

I think the document would be clearer if there where place holder text for making clear the cope points that are to be assigned to the MH type and the option. That way when reading the ready RFC one gets the numbers directly instead of having to go to the IANA section. In general the text is not formulated to make it clear what IANA assigns.

[Ballot discuss]
Section 3., paragraph 0:
> 3.  Heartbeat Mechanism

  DISCUSS: Most of the SHOULDs in this section can be upgraded to MUSTs.
  The "always respond" SHOULD actually needs to become a MUST, because
  otherwise the mechanism doesn't work. I'd also like for the
  HEARTBEAT_INTERVAL SHOULD to become a MUST, or else explain under
  which conditions it is OK to go lower.


Section 3.2., paragraph 0:
> 3.2.  Restart Detection

  DISCUSS: Instead of relying on non-volatile memory for a restart
  counter (which is a pretty limiting requirement), why don't you simply
  create a random nonce at boot that you use until a restart? Peers can
  then simply detect that you rebooted because they see a different
  nonce. (Or am I missing something?)

IANA Last Call comments:

Action 1:

Upon approval of this document, IANA will make the following
assignment in the "Mobility Header Types - for the MH Type field
in the Mobility Header" registry at
http://www.iana.org/assignments/mobility-parameters

Value Description Reference
----- -------------------------------- ---------
[tbd] Heartbeat Message [RFC-netlmm-pmipv6-heartbeat-04]


Action 2:

Upon approval of this document, IANA will make the following
assignment in the "Mobility Options" registry at
http://www.iana.org/assignments/mobility-parameters


Value Description Reference
----- -------------------------------------------- ---------
[tbd] Restart Counter [RFC-netlmm-pmipv6-heartbeat-04]

We understand the above to be the only IANA Actions for this document.

I have reviewed this specification. I did find a few issues, the most serious of which relates to some additional information that you should put to the Security Considerations section. But overall, the issues were minor, so I have sent the draft forward to IETF Last Call; but submit a new version in the next couple of days to fix the problems from my review.

Issues:

> The sequence number field in the unsolicited Heartbeat Response is ignored and no response to necessary

no response is?

>      0                  1                  2                  3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                      |            Reserved      |U|R|
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                      Sequence Number                        |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If you follow the style of message definitions from RFC 3775, you should include the
"Mobility Options" header at the end, as well as describe what options are required
or appropriate.

>  Security Considerations

The security considerations are written in the "just use IPsec" style, which has gotten us into trouble in the past... However, in this case you are employing MH messages, which means that the security policy configuration from RFC 3776 and so on should all be directly applicable. You should state this up front: E.g., "RFCs such and such describe how to protect Mobile IPv6 Binding Update and Acknowledgment signaling with IPsec. The Heartbeat message defined in this specification is merely another subtype of the same Mobility Header protocol that is already under being protected by IPsec. Therefore, protecting this additional message is possible using the mechanisms and security policy models from these RFCs."

> from the same space as the 'MH Type' field
... from the 'MH Type' name space ...

Same issue in the paragraph following this.

Also, the how-to-use-IPsec-with-Mobile-IPv6 RFCs need to be normative references.

Shepherd Write-Up for draft-ietf-netlmm-pmipv6-heartbeat

# (1.a) Who is the Document Shepherd for this document? Has the Document
# Shepherd personally reviewed this version of the document and, in particular,
# does he or she believe this version is ready for forwarding to the IESG for
# publication?

Document Shepherd is Jonne Soininen (WG co-Chair for NETLMM). I have personally
processed and reviewed the document and I do believe the document is ready to be
forwarded for publication


# (1.b) Has the document had adequate review both from key WG members and from
# key non-WG members? Does the Document Shepherd have any concerns about the
# depth or breadth of the reviews that have been performed?

The document has had extensive review by the WG. A WGLC was conducted where some comments were made, which - after discussion - were adopted to the document.


# (1.c) Does the Document Shepherd have concerns that the document needs more
# review from a particular or broader perspective, e.g., security, operational
# complexity, someone familiar with AAA, internationalization or XML?

As the document shepherd, I have no concerns on this document. The document is fairly short and simple and has gotten the review needed.


# (1.d) Does the Document Shepherd have any specific concerns or issues with
# this document that the Responsible Area Director and/or the IESG should be
# aware of? For example, perhaps he or she is uncomfortable with certain parts
# of the document, or has concerns whether there really is a need for it. In
# any event, if the WG has discussed those issues and has indicated that it
# still wishes to advance the document, detail those concerns here. Has an
# IPR disclosure related to this document been filed? If so, please include a
# reference to the disclosure and summarize the WG discussion and conclusion
# on this issue.

I have no concerns on the document.


# (1.e) How solid is the WG consensus behind this document? Does it
# represent the strong concurrence of a few individuals, with others
# being silent, or does the WG as a whole understand and agree with it?

There is a consensus behind the document.


# (1.f) Has anyone threatened an appeal or otherwise indicated extreme
# discontent? If so, please summarise the areas of conflict in separate
# email messages to the Responsible Area Director. (It should be in a
# separate email because this questionnaire is entered into the ID Tracker.)

Nobody has threatned to appeal and the document is product of the WG
effort.


# (1.g) Has the Document Shepherd personally verified that the document
# satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and
# http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
# enough; this check needs to be thorough. Has the document met all formal
# review criteria it needs to, such as the MIB Doctor, media type and URI
# type reviews?

The Document Shepherd has personally verified the document against the id-nits.


# (1.h) Has the document split its references into normative and informative?
# Are there normative references to documents that are not ready for
# advancement or are otherwise in an unclear state? If such normative
# references exist, what is the strategy for their completion? Are there
# normative references that are downward references, as described in
# [RFC3967]? If so, list these downward references to support the Area
# Director in the Last Call procedure for them [RFC3967].

There is a split to normative and informative references.
There is a normative document draft-ietf-netlmm-pmip6-ipv4-support, which is at AD review at the time writing this document.


# (1.i) Has the Document Shepherd verified that the document IANA
# consideration section exists and is consistent with the body of the
# document? If the document specifies protocol extensions, are reservations
# requested in appropriate IANA registries? Are the IANA registries clearly
# identified? If the document creates a new registry, does it define the
# proposed initial contents of the registry and an allocation procedure for
# future registrations? Does it suggest a reasonable name for the new
# registry? See [RFC2434]. If the document describes an Expert Review
# process has Shepherd conferred with the Responsible Area Director so that
# the IESG can appoint the needed Expert during the IESG Evaluation?

Yes, IANA considerations section does exist and seems to be in line with the rest of the document.


# (1.j) Has the Document Shepherd verified that sections of the document that
# are written in a formal language, such as XML code, BNF rules, MIB
# definitions, etc., validate correctly in an automated checker?

No formal languange segments exist.


# (1.k) The IESG approval announcement includes a Document Announcement
# Write-Up. Please provide such a Document Announcement Write-Up? Recent
# examples can be found in the "Action" announcements for approved documents.
# The approval announcement contains the following sections:

Technical Summary
  Proxy Mobile IPv6 has consists of two network elements - Mobile Access Gateway (MAG), and Local Mobility Anchor (LMA). This heartbeat mechanism provides a failure detection mechanism between those    two network elements.

Working Group Summary
  There is a consensus in Netlmm WG that this specification is ready to be
  published as a proposed standard.

Document Quality
  The document has gone through various reviews and a successful WGLC.

Personel
  Responsible AD is Jari Arkko and the document shepherd is Jonne Soininen.