Early Review of draft-ietf-homenet-dncp-03

Request Review of draft-ietf-homenet-dncp
Requested rev. no specific revision (document currently at 12)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2015-07-23
Requested 2015-05-13
Authors Markus Stenberg, Steven Barth
Draft last updated 2015-07-23
Completed reviews Genart Last Call review of -07 by Meral Shirazipour (diff)
Genart Telechat review of -09 by Meral Shirazipour (diff)
Genart Telechat review of -10 by Meral Shirazipour (diff)
Genart Telechat review of -11 by Meral Shirazipour (diff)
Opsdir Last Call review of -07 by Victor Kuarsingh (diff)
Opsdir Telechat review of -09 by Victor Kuarsingh (diff)
Rtgdir Early review of -03 by Les Ginsberg (diff)
Rtgdir Early review of -05 by Thomas Clausen (diff)
Rtgdir Early review of -03 by Lizhong Jin (diff)
Assignment Reviewer Les Ginsberg
State Completed
Review review-ietf-homenet-dncp-03-rtgdir-early-ginsberg-2015-07-23
Reviewed rev. 03 (document currently at 12)
Review result Not Ready
Review completed: 2015-07-23



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.

Document: draft-ietf-homenet-dncp-07

Reviewer: Les Ginsberg

Review Date: July 6, 2015

IETF LC End Date: Seems to have already occurred??

Intended Status: Standard


Major Issues:


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

      for it."






Section 4.4 - final bullet on Page 11


   o  Any other TLV: TLVs not recognized by the receiver MUST be

      silently ignored.


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

advertised (N*(N-1))?



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?