Early Review of draft-ietf-homenet-dncp-03
I have been selected as a Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.
Reviewer: Les Ginsberg
Review Date: July 6, 2015
IETF LC End Date: Seems to have already occurred??
Intended Status: Standard
My biggest concern is that the document - and its companion HNCP - are not
yet mature enough to be doing last call. What is being defined here is a
"state synchronization protocol" which is used within the context of a
"parent protocol" (most interestingly a routing protocol for the homenet
context) and which depends upon another configuration protocol
(presumably HNCP) to fully define the behavior.
Judging from the review comments provided by others (notably Thomas Clausen's
detailed review) and the continued discussion on the mailing list it has not
yet been demonstrated that the specification is clear enough and robust enough
for implementations to meet all the requirements and interoperate.
This is not to suggest that you are on the wrong track - but given the
dependencies pushing this to last call seems - to put it politely -
very "ambitious". I would prefer to see more implementation experience before
the document moves to a state where it is presumed to be complete.
I still have some trouble calling this a protocol. This is more of a process -
or part of a process - which comprises a routing protocol. The process defined
here serves to support reliable distribution and synchronization of "state"
in an efficient manner under a limited set of conditions. I don't want to
quibble too much about the term "protocol" - but I would prefer something like:
"a generic set of procedures which - when supplemented by a specific profile -
define a means of maintaining state synchronization"
Some specific comments on points in the draft follow.
Section 2 Terminology
The term "neighbor" is not defined - but used frequently in the document.
The term "peer" is defined as:
"another DNCP node with which a DNCP node communicates using a particular
local and remote endpoint pair."
What I am used to is that the definition above for "peer" is usually
associated with the term "neighbor", whereas the term "peer" is more generic -
it is associated with a node in the network which performs the same functions
in the protocol - but is not necessarily a neighbor.
Section 4.5 illustrates why I find this confusing as it says
"When receiving a Node Endpoint TLV... the remote node MUST be added as a peer
on the endpoint and a Neighbor TLV (Section 7.3.2) MUST be created
Section 4.4 - final bullet on Page 11
o Any other TLV: TLVs not recognized by the receiver MUST be
Does "ignore mean "discard"? (This is one traditional meaning)
If so this seems inappropriate as it is part of the database sent by
the node and therefore needs to be retained in order to keep a consistent
database. Perhaps "store but do not process" is a more accurate behavioral
Section 6.1 Keep-alives
Here is another case where the confusion between "peer" and "neighbor" arises
for me. I would expect that keep-alives are only used between neighbors -
but the text here uses the term "peer".
Are keep alives sent in multicast-listener mode? >From the text in 6.1.2 and
6.1.3 it seems "no" - but I am not certain.
Section 6.2 Support For Dense Broadcast Links
If a node is in Multicast-listen+unicast mode does it bear any responsibility
for publishing state data in the event the node with highest node identifier
does not have the latest information? I presume yes - but the text does not
discuss this point.
Also, does multicast-listener mode affect the way neighbors are advertised?
It seems not - so what you are preventing w multicast-listener mode is
redundant state updates - but there is no change to the set of neighbors
Section 6.3 Node Data Fragmentation
The significance of the MTU limitation is network-wide i.e. a too large
Node State TLV generated anywhere in the network could cause problems in
some other part of the network. This issue is usually not well understood
as experience w IS-IS has shown. More discussion of this point would be
Second paragraph says
"The data within Node State TLVs of all fragments MUST be valid..."
And if it is not then all fragments are ignored/discarded??
When multiple fragments are used and the location of specific pieces of
information move from one fragment to another cases arise where some data
temporarily disappears and/or there are two copies. Are you addressing this
by expecting that a new set of fragments will not be used at all until all of
them have been received? If so, what happens if you receive some fragments
but not all of them? Is there a timeout to be applied here?
Section 7 TLVs
It says "padding bytes with value zero"".
Is "0' a MUST - or is this the usual "SHOULD be transmitted as zero and
ignored on receipt"?
Section 7.2.1 Node Endpoint TLV
When is this sent and how often?