Re: [homenet] Alia Atlas' Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)

[Steven Barth]

Hello Alia,


thanks for your detailed replies and suggestions.
We have just released a new version which should improve upon the issues you 
have raised.


Please find some more detailed comments inline.


Cheers,

Steven



> I understand that but there were still a number of gaps.  For instance, I see 
> nothing
> that describes how to compute the network state hash.  I would expect a 
> section like:

I refactored the hash-tree section and created
two subsections "Calculating network state and node data hashes" and  "Updating 
network
state and node data hashes" to make it more obvious. I also added a reference 
to the
profile section wrt. hash-function and truncation as you suggested.


> The draft has "Topology graph the undirected graph of DNCP nodes produced by 
> retaining only bidirectional peer relationships between nodes."
> 
> In Section 4.6, I think that you are describing how to create the topology 
> graph,
> rather than "traversing it".   

Updated this section as well, changed "traversing" to "updating". Added some 
more
clarifications and an xref to the hash tree section.



> 
> "Sec 4.5.1  Initiating Neighbor Relationships
> 
> A DNCP profile MAY specify a multicast address on which each DNCP node MUST
> listen to learn about new neighbors.  If multicast discovery is specified in 
> the DNCP
> profile, then when a node starts, it SHOULD send a Node Endpoint TLV to the 
> multicast
> address using ??UDP??.
> 
> In addition to or instead of multicast discovery, a node MAY be configured 
> with a 
> set of DNCP neighbors and the associated interfaces to use.  When a node 
> needs to initiate
> a neighbor relationship, that node SHOULD send a Node Endpoint TLV to the 
> unicast address
> of the desired neighbor.  Note that security considerations may influence 
> whether the relationship
> is established."
> 
> "Sec 4.5.2 Destroying a Neighbor Relationship
> 
> A node can destroy an established neighbor relationship, regardless of 
> whether that node initiated
> or responded to create the neighbor relationship.  A node MUST send a Node 
> State TLV that does
> not include the Node Endpoint TLV with the neighbor's Node Identifier and the 
> associated link's Endpoint
> Identifiers.  A node MAY  information> as part of
> terminating DNCP.

I updated the section on peers and renamed it to "Discovering, Adding and 
Removing Peers".
It should now clarify the points that I think were not obvious based on your 
suggestions.



> 
>  
> 
> >> c) It looks like the TLVs are sent one after another in a datagram or
> >> stream across a socket.  The closest I see to any detail
> >> is "TLVs are sent across the transport as is".
> >
> > Section “4.2 Data Transport” says
> >TLVs are sent across the transport as is, and they SHOULD be sent
> >together where, e.g., MTU considerations do not recommend sending
> >them in multiple batches.  TLVs in general are handled individually
> >and statelessly, with one exception …
> >
> > Could you please be more specific on what is unclear?
> >
> > The section states that TLV handling is stateless except for the one 
> exception
> > which is explained, so otherwise  it does not really matter in what 
> order
> > they are sent or how you split them up onto datagrams (if that is your
> > transport).
> 
> 
> At a minimum, you should specify "in network order" for how the TLVs are sent.

Do you mean that numbers are sent in network byte order? That is already defined
in the section on TLVs. I created a cross-reference there.


> It would be good to specify whether TLVs need to be sent in any particular 
> order.
That was one of the intentions of the stateless parsing sentence, however I 
added
an explanation inside brackets mentioning ordering.

> It'd be nice for the receiver to know whether there's a way of seeing that 
> the last
> TLV in the message has been received so it's easier to avoid doing work 
> multiple
> times.

There are no special resending requirements. Reliability is either provided by
using a reliable transport or based on Trickle. Clarified that.


> When does a node decide to use unicast transport?  When does the node decide
> to use multicast transport?  There are some indications about what is sent, 
> but
> not in a very normative way.

It should be quite normative already. The only TLV that is regularly sent over 
multicast
or that is actively sent (not as a reaction to another packet) is the 
trickle-driven
Network State TLV (accompanied by an Endpoint TLV). The section on 
"Trickle-Driven Status
Updates" has MUST-statements on which transport (mc or uc) to use.

All other TLVs are sent reactively over unicast. I added another clarification.



> 
> When and how does a node take into consideration MTU?  I know this is tied to 
> the profile, but it needs to be discussed here.  Can a TLV be broken across
> multiple packets?

Added that fragmentation and reassembly 

Re: [homenet] Alia Atlas' Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)

[Alia Atlas]

Hi Steven,

On Thu, Oct 8, 2015 at 2:19 AM, Steven Barth  wrote:

> Hello Alia,
>
> unfortunately we haven't gotten any response from you wrt. your DISCUSS on
> DNCP yet.
> We would really like to address the issues you have raised, but would need
> some feedback
> from your side to do so. Please note that we have pushed a new revision in
> the meantime
> and tried to clear off the remaining issues in our mail from September
> 17th which I have
> quoted below again.
>

I was waiting for the updated version and have now read it.

I did find the changes and extra text to be good improvements.

What is missing is frequently absolute clarity on how to do various parts.

If you want, I can take a pass at some more serious restructuring and
writing
some clarifications - but I will only do that if you feel it is helpful.


> Please let us know how to proceed on the matter to resolve your DISCUSS.
>
>
>
> Thanks,
>
>
> Steven
>
>
>
> On 17.09.2015 17:10, Steven Barth wrote:
> > Hello Alia,
> >
> >
> > please find replies inline.
> >
> >
> > Cheers,
> >
> > Steven & Markus
> >
> >
> >> --
> >> DISCUSS:
> >> --
> >>
> >> First,  I have a number of specific comments.   Some of these are
> hazards
> >> to technical interoperability; I've tried
> >> to include those in my discuss - but the general point is that it is
> very
> >> hard to tell a number of details because the
> >> structure is assumed.   Having read this document, I do not think that I
> >> could properly implement DNCP from scratch.
> >
> > Please note that an independent DNCP (or more specifically an HNCP)
> > implementation has been successfully developed based on
> > an earlier version of this draft and has been shown to be
> > interoperable with the reference implementation of the draft authors.
> > We used the implementer’s feedback afterwards to further refine the draft
> > to avoid possible ambiguities.
>

I understand that but there were still a number of gaps.  For instance, I
see nothing
that describes how to compute the network state hash.  I would expect a
section like:

"4.1.1 Computing Node Data Hash

To compute the data hash associated with a node, the TLVs are ordered first
based
on the lowest type and then numerically increasing based on the values.
This creates
a bit string that is input to the Hash Function specified by the DNCP
application profile.  The
length of the output hash is dependent upon the DNCP application profile.
The following gives an example using the fictitious profile given in
Appendix C.

.

A Node Data Hash may be computed for a locally stored node or for a Node
TLV that is
received in the following cases

4.1.2  Computing a Network State Hash

To compute the Local Network State Hash, only the nodes which are
bidirectionally connected
to the local node can be used.  These nodes are determined by the algorithm
given in
Section 4.6 which determines the current network topology graph from the
local computing
node's perspective.  As discussed in Section 4.6, any nodes which are not
reachable
may be removed from the local node's knowledge; at a minimum, such nodes
MUST NOT
be used in computing the Local Network State Hash.

To compute a Received Network State Hash, the local node uses the
information from the
associated received Node TLVs.  If Node Data is included in a Node TLV,
then an updated
Node Data Hash MUST be computed as described in Sec 4.1.1.  Otherwise, the
Node Data
Hash contained in the Node TLV MUST be used.  . It is assumed that all
nodes included in the
Network State TLV are considered to be bidirectionally reachable by the
originating node.

To compute either a Local or a Received network state hash, the nodes are
ordered based
upon their node identifiers in increasing numerical order.  Each node is
checked to see that
it has an updated Node Data Hash.  A node is considered to have an updated
Node Data Hash if 
If a node doesn't have an updated Node Data Hash, then that must first be
computed before
the Network State Hash can be computed.  Finally, the bit string created by
taking the Node Data
Hash of each node in the specified ordered is input to the Hash Function
specified by the
DNCP application profile.  The  length of the output hash is dependent upon
the DNCP
application profile.

The following is an example using the fictitious profile given in
Appendix C.

...


The Local Network State Hash is recomputed when 
"


>> a) What is a topology graph?  When is it created, modified, or destroyed?
> >>  Is it a conceptual artifact constructed
> >> from the various TLVs?  I think a quick paragraph describing it would
> >> help.
> >
> > The term “topology graph” is defined in the Terminology Section and based
> > on bidirectional peer reachability which is defined right afterwards. In
> the
> > latter definition it is mentioned that 

Re: [homenet] Alia Atlas' Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)

[Steven Barth]

Hello Alia,


please find replies inline.


Cheers,

Steven & Markus


> --
> DISCUSS:
> --
>
> First,  I have a number of specific comments.   Some of these are hazards
> to technical interoperability; I've tried
> to include those in my discuss - but the general point is that it is very
> hard to tell a number of details because the
> structure is assumed.   Having read this document, I do not think that I
> could properly implement DNCP from scratch.

Please note that an independent DNCP (or more specifically an HNCP)
implementation has been successfully developed based on
an earlier version of this draft and has been shown to be
interoperable with the reference implementation of the draft authors.
We used the implementer’s feedback afterwards to further refine the draft
to avoid possible ambiguities.


> a) What is a topology graph?  When is it created, modified, or destroyed?
>  Is it a conceptual artifact constructed
> from the various TLVs?  I think a quick paragraph describing it would
> help.

The term “topology graph” is defined in the Terminology Section and based
on bidirectional peer reachability which is defined right afterwards. In the
latter definition it is mentioned that the process is solely based on published
TLVs so the topology graph is to my understanding already unambiguously
defined. It is solely up to the implementer if this is implemented as an actual
graph or not, as long as the outcome is consistent with what is described.

If you still think it is ambiguous please provide some ideas on how this
could be worded better.


> b) How are peer relationships discovered and established and destroyed?
> I really can't tell from the draft and even a quick scan of
> RFC 6206 doesn't give any hints.

This is explained in section “4.5 Adding and Removing Peers”. As for
methods for discovery, this is actually mentioned multiple times across
the document, e.g. in the second paragraph of the Overview or in the
terminology.

Could you please be more specific on what exactly is unclear here in your
opinion?


> c) It looks like the TLVs are sent one after another in a datagram or
> stream across a socket.  The closest I see to any detail
> is "TLVs are sent across the transport as is".

Section “4.2 Data Transport” says
   TLVs are sent across the transport as is, and they SHOULD be sent
   together where, e.g., MTU considerations do not recommend sending
   them in multiple batches.  TLVs in general are handled individually
   and statelessly, with one exception …

Could you please be more specific on what is unclear?

The section states that TLV handling is stateless except for the one exception
which is explained, so otherwise  it does not really matter in what order
they are sent or how you split them up onto datagrams (if that is your
transport).


> d) As far as I can tell, Trickle is used to decide basically how often to
> send information - but the details of this and the interactions
> aren't clear to me.

This is explained in detail in section “4.3.  Trickle-Driven Status Updates”.

   The Trickle state for all Trickle instances is considered
   inconsistent and reset if and only if the locally calculated network
   state hash changes.  This occurs either due to a change in the local
   node's own node data, or due to receipt of more recent data from
   another node.  A node MUST NOT reset its Trickle state merely based
   on receiving a Network State TLV (Section 7.2.2) with a network state
   hash which is different from its locally calculated one.

   Every time a particular Trickle instance indicates that an update
   should be sent, the node MUST send a Network State TLV…

Could you please be more specific on what is missing here?


> I suspect that there are dependencies on the HNCP draft that would make
> this a lot easier to understand but since we want it to progress
> separately, the document does need to stand alone.

No, there are no dependencies. This was noted already in response to
reviews from Thomas Claussen and Les Ginsberg.

Please refer to section “9.  DNCP Profile-Specific Definitions“ for the
comprehensive list of things we have intentionally left out in DNCP.


> 8) In Sec 4.6 "   o  The origination time (in milliseconds) of R's node
> data is greater
>   than current time in - 2^32 + 2^15."  Since origination time hasn't
> yet been introduced, I'm going
> on an assumption that it means when R's node data was originated from R.
> So - this requirement is
> saying that R's node data must have been generated in the future (but
> already known by the local node)???

The term “origination time” is actually explained in Section “5. Data Model”,
-10 will have a forward-reference here. About the time itself,
the text says greater than “current time - 2^32+2^15”; that threshold is always
in the past.


> 9) In Sec 4.6 "They MAY be