Heartbeat Mechanism for Proxy Mobile IPv6
Note: This ballot was opened for revision 07 and is now closed.
(David Ward) Discuss
Discuss (2009-03-11 for -** No value found for 'p.get_dochistory.rev' **)
Why isn't this based on BFD with large intervals?
(Jari Arkko) Yes
(Dan Romascanu) Yes
Comment (2009-03-12 for -** No value found for 'p.get_dochistory.rev' **)
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'?
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lisa Dusseault) No Objection
(Lars Eggert) (was Discuss) No Objection
(Pasi Eronen) (was Discuss) No Objection
(Adrian Farrel) No Objection
Comment (2009-04-02 for -** No value found for 'p.get_dochistory.rev' **)
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.
(Russ Housley) No Objection
(Cullen Jennings) No Objection
(Jon Peterson) No Objection
(Tim Polk) (was No Record, Discuss) No Objection
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...
(Mark Townsley) No Objection
(Magnus Westerlund) No Objection
Comment (2009-03-11 for -** No value found for 'p.get_dochistory.rev' **)
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.