Early Review of draft-ietf-homenet-dncp-03
review-ietf-homenet-dncp-03-rtgdir-early-ginsberg-2015-07-23-00

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?