Les, Thanks very much for your review.
Alia On Tue, Jul 7, 2015 at 1:25 AM, Les Ginsberg (ginsberg) <[email protected]> wrote: > 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? > > > > > > > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet > >
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
