Heartbeat Mechanism for Proxy Mobile IPv6
RFC 5847
Discuss
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
Lars Eggert (was Discuss) No Objection
(David Ward; former steering group member) Discuss
Why isn't this based on BFD with large intervals?
(Dan Romascanu; former steering group member) Yes
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'?
(Jari Arkko; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
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.
(Cullen Jennings; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
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.
(Mark Townsley; former steering group member) No Objection
(Pasi Eronen; former steering group member) (was Discuss) No Objection
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Tim Polk; former steering group member) (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...