Hello, 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 http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir 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 description?   ******************** 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 helpful.   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?