> On Jul 29, 2015, at 13:06, Markus Stenberg <markus.stenb...@iki.fi> wrote:
>
> First of all, thanks a lot again for review comments; I think you are the
> most critical reviewer we have had yet, and it helps to improve the document
> quality a lot :)
I *was* starting to worry if I needed to take out armed protection, simply due
to the sheer volume of my comments appearing as a “late assault” :D I am
thrilled that I didn’t need to, and that to the contrary you really reflected
them well in the spec.
> We have had a number of reviews by this point, but I believe you have raised
> order of magnitude more changes than the second in line who also lives in
> Paris; is this a coincidence? I think not.
Fun that you should mention it. I think that the person you refer to, and I,
while we’re based in the same area, never actually have seen each other
(despite repeatedly planning for it) in or around Paris. So rest assured, it’s
not a “geographic conspiracy” afoot here ;)
> Anyway, on to comments..
>
> Caveat: These are my comments, Steven is likely to fix typos before we
> actually hit publish button on -09 :)
>
> Executive summary: Minor edits, but as you are good with words, time to ask
> for advice - how would you explain “Endpoint” in the terminology? (Anyone
> else on the list too, feel free to chime up..)
>
Actually, when doing my review I tried if I could come up with some text that I
would thing worked — which, if I had succeeded, I’d have been throwing it at
you saying “…but this would make me happy”.
I didn’t come up with something that I actually liked. So instead, you get my
random thoughts …
> Fact: It is not socket. I consider it essentially bidirectional mapping
> between an endpoint #, and some transport details (as it is used for both
> receiving and sending traffic).
I guess I am troubled by having seen the terminology “a socket is an endpoint
for communication” and “a connection is a pair of sockets” — taking from
Wikipedia (which is not a source for anything but “what is commonly used, even
if incorrectly - but, as such, is a good way to understand “how many people
would misunderstand in the same way"):
"A network socket is an endpoint of an inter-process communication
across
a computer network. Today, most communication between computers is
based on the Internet Protocol; therefore most network sockets are
Internet sockets."
Now, I am of course also troubled by the recursive definition of endpoint in
the I-D:
Endpoint: a locally configured communication endpoint of a DNCP node,
such as a network socket.
> Random examples from existing implementations:
>
> - _a rule_ that matches that stuff from ::1 is endpoint #1 (on shared socket)
> - _a rule_ that we try to contact 2001:db8::1 and denote it as endpoint #2
> (on shared socket)
> - a socket which is bound to eth0 + port X, and listens to multicast there,
> denoted as endpoint #3
> - (shared socket on port Y) which is listens to eth1 multicast (and also
> deals with eth1 link-local unicast traffic), denoted as endpoint #4
>
So that sounds a little bit like (for the 2nd bullet) that it’s (in part) a
“connection” (the “we try to contact ….” part)?
> The current text-monster is as follows:
>
> Endpoint a locally configured communication endpoint of a DNCP node,
> such as a network socket. An endpoint may be bound to a set of predefined
> unicast Addresses representing remote DNCP nodes to individually connect to
> or to accept connections from whereby communication with each node is
> separated (e.g., an individual unicast UDP message flow per remote node). An
> endpoint may also be bound to a whole network interface, then multicast
> communication is used (in addition to individual unicast flows) to send
> certain messages to all DNCP nodes connected therewith at once as well as to
> automatically discover new DNCP nodes. Endpoints are usually in one of the
> transport modes specified in Section 4.2.
>
> On 28.7.2015, at 18.45, Thomas Clausen <i...@thomasclausen.org> wrote:
>> Authors, for all the points where I have said “fine”, if you reply to this
>> mail feel free to cut those points out and retain only outstanding issues.
>> OK; on a personal-preferences level, the separation between HNCP and DNCP
>> seems artificial, and it probably is part of the reason why this is hard to
>> describe. I probably would not have made that separation myself — but I am
>> not suggesting that the WG goes back on that decision (just to be clear),
>> rather that it be called out.
>>
>> I can live with what is there.
>
> I think the separation makes sense (as DNCP itself is generic algorithm, more
> or less); however, the point of separation I am not so sure about (e.g.
> concrete TLVs in DNCP feel bit wrong, but there are reasons for that too;
> easier to specify DNCP-based protocols).
As I said, I am not suggesting to go back on that decision — so we can have
that discussion somewhere away from the ears of the ADs some other time ;)
>>> We reorganised the document a bit, wrote a better abstract and
>>> introduction and provided a “Protocol Overview” section, on top of that
>>> we reorganised the details in an “Operations” section.
>>
>> OK; I am a good deal more happy now, although not perfectly happy just yet.
>>
>> I still think that it would be fantastic to have an applicability statement
>> included. Reading the document without any context [as it might down the
>> line if it was to become an RFC], it’s hard to understand if “hey, I have a
>> problem, is DNCP the right lump of metal to use to make a hammer for it?”
>
> Adding one in -09; however, it is still undergoing edits. Gist of it is to
> look at
>
> [1] min (keepalive-interval-if-nonzero, churn frequency * number of nodes)
> and compare it to Trickle parameters chosen
> [2] consider amount of TLV change within TLV sets published by nodes (large
> set, small changes => may not be the best protocol for the job due to lack of
> per-TLV deltas)
Sounds good.
>> As I said in my original review, I think that this is a matter of scoping
>> the work right. The abstract, and the into, calls out “a generic state
>> synchronization protocol” — I’ve heard OSPF described as such, also (hi
>> Fred!) — which sounds very much like “boiling the ocean”, and which I think
>> the WG is not trying to actually do.
>
> WG isn’t, but we wound up doing one anyway. Still, we’re adding applicability
> subsection in 09, as I think it is important to note that DNCP is _not_ the
> tool for many things.
Great, sounds like we’re perfectly aligned here, and I look forward to seeing
the text.
>
>> Why don’t you put a subsection before the last paragraph of the Introduction
>> “Applicability” and then expand on that?
>
> Addressed above.
>
>> I just want to note that I enjoyed the expanded terminology - thank you!
>> There may be a small formatting snafu, at least in the HTML version, about
>> missing blank lines between (for example) “Address” and “Endpoint”
>
> Hopefully fixed.
>
>> Going back and looking at that, does it make sense to talk about “DNCP
>> network”, out in the real world, or just in this document?
>>
>> An HNCP network and a TNCP network (that’d be for "Thomas' Neat
>> Configuration Protocol”) sure, and such two could co-exist (but not
>> interoperate) so while they “in the abstract” would both be instances of
>> DNCP networks, that’d be an abstract construction altogether.
>>
>> Could I suggest that to the definition of “DNCP network” some verbiage to
>> that effect be added?
>
> NEW: a set of DNCP nodes running DNCP-based protocol(s) that have matching
> DNCP profile.
>
> The side effect is that if DNCP profiles match, essentially transit service
> is provided even if the implemented protocol is not same. (e.g. HNCP + SHSP
> currently.)
And that *sounds* right and *sounds* as if it is by design, so that’s great.
>
>> Now we’re at tightening up on terminology, I am finding myself wondering
>> about “DNCP profile” and “DNCP-based protocol” as terms, just a little.
>>
>> A DNCP profile is
>> a definition of the set of rules and values
>> defining the behavior of a fully specified,
>> implementable protocol which uses DNCP. The DNCP
>> profile specifies transport method to be used,
>> which optional parts of the DNCP specification are
>> required by that particular protocol, and various
>> parameters and optional behaviors. In this
>> document any parameter that a DNCP profile
>> specifies is prefixed with DNCP_. Contents of a
>> DNCP profile are specified in Section 9.
>>
>> Could we be a little bit more succinct:
>>
>> “A DNCP profile consists of:
>> o The values for the set of parameters, given in
>> section 9.
>> o The set of optional parts of this
>> specification, which are to be used.”
>
> Adopted the gist of it, although not going to convert to a list (and retained
> DNCP_ note as it is useful to understand DNCP_foo coming up shortly in the
> next few things).
>
Yes, the DNCP_ note should be retained. My bad for *not* doing that, thanks for
catching it.
> NEW:
> DNCP profile consists of the values for the set of parameters,
> given in Section 9. They are prefixed with DNCP_ in
> this document. It also specifies the set of
> optional parts of this specification, which are to
> be used.
>
Works for me.
>
>> For DNCP-based protocol, the doc says:
>>
>> A DNCP-based protocol is:
>> a protocol which provides a DNCP profile, and
>> potentially much more, e.g., protocol-specific TLVs
>> and guidance on how they should be used.
>>
>>
>> Could we be more precise (than “potentially much more”) on “DNCP-based
>> profile”
>>
>> “A DNCP-based protocol is:
>> o A DNCP profile, according to Section 9,
>> o Zero or more TLV assignments from the
>> registries set up by this specification
>> o generation and processing rules for these TLVs
>
>
> NEW:
> DNCP-based protocol a protocol which provides a DNCP profile, according to
> Section 9, and zero or more TLV assignments from the DNCP profile-specific
> TLV registry as well as their processing rules.
>
Works.
>> On the definition of “Address”:
>>
>> o What does it mean to be “relatively transport agnostic”? I’d
>> say that it’s a little bit like being “relatively pregnant” —
>> either you are, or you are not?
>
> Got rid of some relatively’s.
>
;)
>> o Why not define an “Address” as (IPv6-address, Transport, Port)?
>> (and then, if someone comes along with something that doesn’t
>> fit that tuple form
>> down the line, deal with it then?)
>
> I am not sure it would help as such. The addressing may also occur inside
> transport - think multiple flows multiplexed over single stream connection,
> for example. Or local UNIX domain sockets :)
OK, but now I am back to being confused — how does “multiple flows multiplexed
over single stream connection”, “address” and “endpoint” then fit together?
>
>> Address, by the way, uses “endpoint” which is defined below.
>
> Transport protocol endpoint and DNCP endpoint are not neccessarily the same
> thing. They may have 1:1 relationship, but also 1:N (or possibly M:N) are
> possible. Got rid of endpoint in the new definition.
>
> NEW:
>
> Address an identifier which specifies how to reach a particular
> instance of a transport protocol on a particular node. In case of an IPv6 UDP
> transport, an address in this specification refers to a tuple (IPv6 address,
> UDP port).
*mumble* - Let me give this whole part some thought, and see if I can come up
with something constructive to say on this point (other than “not sure that
that’s clear”).
>> Endpoint, then, ends up being defined almost as an “address” *except* that
>> there’s the clause “may be bound to a set of predefined unicast addresses”
>> [would those be addresses as previously defined?]
>>
>> When I read “Endpoint” I end up simply thinking “Socket, expressed as
>> (IPv6-address, Transport, Port)” but as that was defined above it can’t be
>> it?
>>
>> Could you clear that up, please? [Note, it’s better than the -05, but still
>> confusing]
>
> I am not sure how. There has been literally half dozen iterations so far. I
> am not sure I like the current one, as it is overly verbose and apparently
> not much closer to the goal.
>
> (see top)
Yup. Needs some thought here. I’ll peg that as a todo; if we end up with that
as the only outstanding point, and we’re no closer to an alternative, then the
conclusion could be “Thomas is just too dense to understand this”, which I
trust that the ADs would be comfortable with.
>>>> Major Issues:
>>>>
>>>> o The introduction does not read well; it contains parts of
>>>> something that
>>>> could be considered as part of an applicability statement
>>>> (without it
>>>> being called out as such, and without forming a complete
>>>> applicability
>>>> statement), and does not actually introduce the protocol.
>>>> Reading just
>>>> the introduction and the abstract, it is very obscure if
>>>> this is a framework, a protocol, a building block, an
>>>> architecture, an
>>>> algorithm -- and, if either of those, what it is actually
>>>> accomplishing,
>>>> and why one would chose to use DNCP. It does, however,
>>>> transpire that
>>>> "whatever it is", it has two "modes" and that it requires
>>>> something
>>>> (presumably a routing protocol) to provide each "node" with a
>>>> topology
>>>> map.
>>>>
>>>> Suggest that a proper introduction consisting of three parts
>>>> would be
>>>> beneficial: (i) what this document is, (ii) what doing DNCP
>>>> actually
>>>> gets you, and (iii) the operating conditions under which the
>>>> DNCP is applicable.
>>>>
>>>> On the latter point, given that you state that DNCP requires
>>>> profiles
>>>> to provide "actual implementable DNCP based protocols", it
>>>> appears
>>>> important to understand what the limits for "what a profile can
>>>> give
>>>> you" are.
>>>>
>>>> I am calling this out as a major issue, since I believe that it
>>>> is
>>>> not just editorial, but is a matter of scoping this document
>>>> correctly,
>>>> and in particular not falling into the trap of "claiming
>>>> applicability
>>>> where it's not".
>>>
>>> As noted earlier, the introduction has been reworded and separated from
>>> protocol overview also considering your suggestions.
>>
>> So this is good, thank you for doing that effort — it’s tedious, but it
>> helped.
>>
>> To section 3, therefore, a few suggestions:
>>
>> 1) Throw an initial paragraph in stating what DNCP does “state
>> synchronization” and all that.
>
> As this comes after the intro (which does that), I am not sure I agree with
> the need. Do you suggest cut-n-paste, or something new here?
Well, “A TLV-based distributed state synchronization protocol, DNCP operates
primarily using unicast exchanges…” as the first sentence would really do it
for me.
>
>> 2) “DNCP discovers the topology of its nodes and …”
>> Argh…almost there “its nodes”?
>> - would that be “the nodes in the DNCP network”
>> (which has been defined…)?
>> - you’re discovering the topology (i.e., you
>> actually produce a topology graph?)
>> or just the presence or absence of nodes in the
>> network (i.e., a destination list)?
>> Just state what you do, and it’ll be good.
>
> Using the first suggested text. Of course, this ’topology’ may be somewhat
> misleading too as we do not really necessarily have low-level topology, but
> just connectivity among DNCP nodes. *sigh*
>
> (In point-to-point case, there may be arbitrary number of hops in the middle
> DNCP is blissfully unaware of.)
That works.
>
>> 3) “bidirectionally reachable” — call out if that means “over one
>> IP hop” (as in “on the same link”)
>> or if it can be “bidirectionally reachable, possibly through a
>> multi-hop path”
>>
>> Actually, why don’t you define that term in the terminology
>> section, since it appears also
>> in section 4, and it’d make me go away with this comment in
>> more places than one ;)
>
> Hmm. Given we leave actual transport out, I am not sure how it could be over
> one IP hop.
>
> Anyway, added a definition (not cut-n-pasting here so Steven has time to fix
> it, cough).
>
OK, I’ll wait to see what comes
>> 4) “A hash tree is maintained by each node” — I’ve thought about
>> that, and I think that you may
>> want to expand a little more. “A hash tree, rooted in itself,
>> is maintained by each node”?
>> 5) And then, again, the text is almost there, bit just need a
>> nudge…how is the tree constructed?
>> You start fine “a node starts with a hash tree only consisting
>> of itself”.
>> Then it announces that, and gets updates. How are those
>> “integrated” into the receiving nodes’
>> hash tree.
>> Yes I know how it’d work out (I may be dense, but not *that*
>> dense ;) ), but I think that it’d be
>> easy to capture all here and being complete, since it’s so
>> close.
>>
>> By the way, I would state that the hash tree is height 1 in this section,
>> and add a forward reference to 4.1.
>
> Added some forward refs, and updated the text.
>
> A hash tree of height 1, rooted in itself, is maintained by each node to
> represent the state of all currently reachable nodes (see Section 4.1) and
> the Trickle algorithm is used to trigger synchronization (see Section 4.3).
>
Awesome, clear now.
>> Section 4, I really like what you have done with it also. As a purely
>> subjective matter, could there between 4 and 4.1 be some educational text
>> that describes how the 6 subsections to 4 “fit together”? As it is right
>> now, it’s a little abrupt.
>>
>>>> o The document, in my understanding, defines an exchange format
>>>> with
>>>> limited ability to evolve, as simply "a steam of TLVs".
>>>>
>>>> As long as there's never a need to evolve the TLV format
>>>> itself, and
>>>> as long as you do not run out of TLV types, that's not going to
>>>> be
>>>> a problem. The doc sets aside a 16bit TLV type space, that's
>>>> reasonable
>>>> enough, but I worry if eventually a DNCPv2 will need to evolve
>>>> the
>>>> format. One purely hypothetical example could be if a "sequence
>>>> number"
>>>> would be needed in each DNCP message to detect "link success
>>>> rates", or
>>>> something of that sort.
>>>
>>> I think on this front we have to agree to disagree; as it is a stream of
>>> _unrelated_ TLVs with some rare exceptions (node endpoint ID => network
>>> state), a later spec such as DNCPv2 can specify if it wants to that
>>> every DNCP 'message' contains TLV of type $FOO and uses disjoint set of
>>> TLVs to do X. Hell, we do that in HNCP already.
>>>
>>
>> OK, then, in that case what you call a TLV is what I would call a “Message”
>> — fair enough, I can do that mental substitution.
>>
>> Now…that still doesn’t change the fact that you may end up having to evolve
>> your Message format — I’m sorry, your TLV format — as it appears on the
>> wire, as well as some of the behaviors that you exhibit through DNCP
>> processing.
>>
>> For that, you’ll need a version number. And again, I am sorry, I cannot come
>> up with a concrete example and — again — that’s part of the dilemma: a
>> future extension that we have not thought about is, by definition, a future
>> extension that we have not thought about and so therefore we can’t predict
>> if it will be interoperable with a what we have now.
>
> TLV space is relatively large, and mostly undefined. I still do not see the
> problem.
>
> I see much more of a problem defining e.g. 4 byte version thing, because
> after that speaking ‘both versions’ of the protocol becomes hard.
>
Alright, I’ll peg that as issue #2 that needs an isolated discussion and where
the ADs may have to decide that I am in the rough (which is fine) if needed. I
just observe that I’ve seen a strong move in other contexts in the IETF for
“version numbers” so I would expect that to become an issue here also.
>>>> I do not have an actual example in mind -- and that's exactly
>>>> the point:
>>>> to be evolutive for the unknown future and (at the very least)
>>>> be able
>>>> to discriminate between "old" and "new".
>>>>
>>>> A discussion could be had if a "version number" in each TLV
>>>> would do,
>>>> or if a concept of "protocol message with a version number" is
>>>> preferential. I do not believe, however, that "no version
>>>> number" is
>>>> viable.
>>>
>>> Since DNCP is an abstract protocol, a concrete protocol on top of it
>>> might probably want to do versioning for its own purposes (i.e.
>>> different versions on top of the same DNCP version). In this case having
>>> versioning in both DNCP and the derived protocol serves little purpose.
>>> HNCP - as first derived protocol - defines a Version-TLV btw.
>>
>> Yes but that is a “version TLV” — what happens if the TLV format itself, or
>> some of the DNCP specific processing.
>>
>> This, incidentally, goes to the crux of why I — personally — would not have
>> done the split. Had DNCP *exclusively* been an algorithm, or such, then I
>> could see not needing a version in DNCP, but in the DNCP-based protocol
>> (HNCP) only. Or, for that matter, had DNCP been just a frame format with no
>> processing, or something, then I could see one sequence number sufficing.
>>
>> By DNCP being part-signals-part-procesing-part-behavior-part-framework,
>> which cannot exist on its own but which requires “another protocol which
>> profiles it and which also defines its own signals, processing, and
>> behavior”, yes, you actually having this “version number conundrum”.
>
> Why? The concrete DNCP-based protocol actually says what it supports, and
> e.g. future DNCP extensions are not implicitly part of HNCP, unless we
> specify them to be.
It’s always hard to speculate on extensions, so … this may sound silly.
Say we wanted DNCPv2 to, for some reason, not use TLVs but use LVTs, or that it
redefined the way of calculating the Network State / Node State — for some
reason. For the LVT-option you’d be screwed ;) for the “new way of calculating
Network State / Node State” you’d say “define a new TLV type”?
I’d imagine that a DNCPv2, or perhaps a device using DNCPv2, would somehow be
able to maintain a “backwards compatible mode”, say, if I see DNCPv1-based
protocols hanging around, then I’d probably fall back to use those, but if I
don’t then I’d want to use the new-fancy DNCPv2-based protocols (which might
use some of the same TLVs, but use them differently).
I think that you’re shooting yourself in the foot here.
>
>> You could not fix all this by having a DNCP version number only, but having
>> a sufficiently large TLV type space? That way, you’d not need (say) HNCP
>> version numbers, but a HNCPv2 would use TLV types A, B and D (but not C)
>> from HNCPv1, and would reserve and define TLV types X, Y, Z ?
>
> HNCP has 2^16-few types to play with. Is that not enough?
>
> (Only up to 32 and the local tinkering range are excluded from the DNCP
> profile specific registry HNCP will set up. However, conflicts in handling
> the 256+ range are currently being considered on how they should be handled.)
Proposal….you say that you have a large TLV type space so ….why don’t we set
aside the first two bits in the TLV type field, call that “Version”, and define
“if both are cleared, then it means this specification, DNCPv1" and then have
2^14 “TLV types” — with a potential for 4 DNCP “versions”?
Then, we take an appointment in 15 years time. If by then we still have not
found a reason to flip either of these two version bits, then (i) we write an
“Updates DNCPv1” RFC which reassigns that field as “16 bit TLV Type”, and I buy
lunch — otherwise, lunch is on you?
;)
>
>>>>
>>>> o Noting that the "overhearing n reduncant transmissions" is a key
>>>> retransmission suppression mechanism in Trickle, and that this
>>>> seems to assume broad/multicast, using unicast seems to
>>>> contradict
>>>> the statement of "consists of Trickle", at least in the way the
>>>> algorithm is defined in RFC6206. Note: it's fine to use an
>>>> algorithm
>>>> outside of its initial scope, but it should be with the caveat
>>>> of
>>>> "which of the characteristics still hold, and which do not"
>>> If k < 2, even on point-to-point link, Trickle does reap benefits and
>>> provides exponential backoff timer. Obviously, we can spell this out
>>> more explicitly if it helps.
>> YES, that sort of explanation would be good.
>
> Added that to the applicability subsection too. (Pending Steven check, *grin*)
>
Great
>>>> o Section 5.3, penultimate paragraph:
>>>>
>>>> "If keep-alives specified in Section 6.1 are NOT sent
>>>> by the peer
>>>> (either the DNCP profile does not specify the use of
>>>> keep-alives or
>>>> the particular peer chooses not to send keep-alives), some
>>>> other
>>>> means MUST be employed to ensure its presence. When the
>>>> peer is no
>>>> longer present, the Neighbor TLV and the local DNCP peer
>>>> state MUST
>>>> be removed."
>>>>
>>>> "...some other means MUST be employed to ensure its presence."
>>>> --
>>>> followed by more MUST verage when a peer disappears...I am not
>>>> sure that
>>>> that's conductive to interoperable implementations.
>>>>
>>>> Two implementatons may chose different "means" and then turn
>>>> off keep-
>>>> alives - and be non-interoperable.
>>>>
>>>> For interoperability, we need:
>>>>
>>>> o A mandatory to implement mechanism,
>>>> that always is
>>>> present, but can be complemented by
>>>> another "means", or
>>>>
>>>> o A mandatory to implement mechanism,
>>>> which by way of a
>>>> specified negotiation mechanism can be
>>>> turned off between
>>>> two peers, to allow them to use another
>>>> "means".
>>>>
>>>> If you argument is "...this will be specified in the profile",
>>>> then
>>>> you still should provide the two above in this document, with
>>>> the note
>>>> that "...and a profile may specify which from among these MUST
>>>> be
>>>> used in a given deployment"
>>>
>>> Clarified that “other means”, refers to existing transport-provided
>>> mechanism, e.g. Ethernet carrier-detection, TCP keep-alives etc.
>>
>> Alright, good. Now where is it specified which is to be used? Is that part
>> of the profile, or should it be? If so, call that out here.
>>
>> I’m trying to avoid interoperability issues, for example if I am using “TCP
>> keep-alives” and you are using something else, can we work together? If this
>> is not a problem, call that out as something which a device can do as it
>> sees fit (although, for example. TCP keep-alives presumably expects TCP
>> which is a profile matter …)
>> I *think* that we are almost there also with this point, so convince me that
>> the text there won’t cause interoperability issues? Hiving it off to a
>> profile to specify would do just that (of course, I’d come back on that in
>> HNCP, instead ;) ).
>
> This (like many other things in the spec actually) are local implementation
> choices; the MUST is that _a method_ must be used (if no keep-alives are
> used).
>
> However, to cover the case without any method available, added following:
>
> If the peer does not send keep-alives, and no means to verify
> presence of the peer are available, the peer MUST be considered no
> longer present and it SHOULD not be added back as a peer until it
> starts sending keep-alives again.
>
That seems to work for me. Thanks
> .. omitted security stuff.
>
>>>> Minor Issues:
>>>>
>>>> Introduction:
>>>> o 1st paragraph: "reachable nodes"; two things:
>>>>
>>>> - I always have a problem with the term
>>>> "node"; it is often
>>>> used as a shorthand for "routers and
>>>> hosts, both". I was
>>>> given to understand that homenet
>>>> specifically did not want
>>>> to consider host changes?
>>> DNCP is not strictly speaking about homenet (but a strict requirement
>>> for HNCP which is). Also even in homenet-case non-routers may join the
>>> network temporarily in order to e.g. do monitoring.
>>
>> But, would those “non-routers” not speak at least part of the “home net
>> specific protocols” and thereby not be “hosts” in the “got them from Best
>> Buy and just clicked OK” sort of sense?
>>
>> So is the crux that we have “homenet-aware devices” and “legacy hosts”, and
>> that either of us just need to get with the program? If so, can I insist
>> (gently) on “homenet-aware devices” [with a suitable definition] instead of
>> “nodes” since “nodes” are such an overloaded term that it’s not even fun any
>> more.
>
> Again, this has nothing to do with homenet, but it’s being pushed in homenet
> just because it is strict dependency on HNCP.
>
> There is already one existing use of DNCP which is very non homenet, demoed
> in IETF93 BnB and presented in the WG; I expect there might be more if we do
> not make the spec overtly homenet-y.
Ok, being general where it makes sense is good. We’ll take this discussion in
HNCP, then.
>>>> - "Reachable" - does that mean something
>>>> as in "radio range",
>>>> does it mean "on the same link", does
>>>> it mean within a
>>>> specific (DNCP?) domain, or does it
>>>> mean simply "on the
>>>> Internet somewhere"?
>>> Clarified in the text as “bidirectionally reachable”, also added
>>> fwd-references to actual definition.
>> Suggest also defining in Terminology, and clarifying if this is a one-hop,
>> or a multi-hop-within-the-homenet, concept. In section 1, I do not see a
>> forward reference, btw, at least not in latest rev.
>
> Added rather verbose description.
;)
>
>>>
>>>>
>>>> o DNCP network: I read this twice, and came away with two
>>>> different
>>>> understandings, perhaps you can clarify which it is:
>>>>
>>>> o A set of nodes running DNCP, within the
>>>> same domain, and
>>>> for which a path betwen any two DNCP
>>>> nodes includes only
>>>> other DNCP nodes; i.e., a DNCP network
>>>> forms a connected
>>>> component with only other DNCP nodes.
>>>>
>>>> o A set of nodes running DNCP. They may
>>>> be anywhere on the
>>>> Internet, they are part of the same
>>>> DNCP network as long
>>>> as they (through other means) have
>>>> learned of each others
>>>> addresses.
>>>>
>>>> In the former, that'd be (for example) a deployment
>>>> within my
>>>> home -- in the latter, it could be a node in my home
>>>> and a node in
>>>> your home forming a DNCP network.
>>>>
>>>> The text is not quite clear on this point.
>>> Both are valid use cases; hopefully clarified.
>> OK, sadly you clarified it ;) Well, no, not sadly, but you clarified it to
>> be understandable to me in the above sense. But, if I come up with the
>> aforementioned TNCP and I use the same transport as HNCP, would a TNCP and a
>> HNCP node be on the same DNCP network, then?
>
> Yes. E.g. SHSP and HNCP share transport, but are ships passing each other in
> the night as far as understanding TLVs go. (And unwittingly, they proxy each
> other’s state.)
OK, with the proposed text somewhere up above in this email, this is clear — so
that works for me also.
>>>> o Link: a point of clarification here. In "DNCP network",
>>>> there was
>>>> talk about "unidirectional links" and "bidirectional
>>>> links"; in
>>>> "Link" the definition is somewhat vague "directly
>>>> connected" and
>>>> "can communicate". Could something like "without
>>>> decrementing TTL/
>>>> hop-count" be added, and could a statement on
>>>> bidirectionality
>>>> (IOW, that this is just an IP link) be added?
>>> This isn’t IP specific as such; however, some better definition is
>>> welcome. some types of IP links are not strictly bidirectional either
>>> (hello, mesh).
>> Hi, you rang? ;)
>>
>> Actually “some mesh protocols” do go through the exercise of verifying
>> bidirectionally before even considering them as useful for whatever the
>> protocol tries to do.
>>
>> What I am trying to get at, though, is not this discussion but rather: what
>> does this Link present to the IP layer, in terms of properties?
>
> (802-style) broadcast domain is what we’re probably looking for. There’s also
> ‘multiple access link’ in one place in the spec, to denote availability of
> link-local multicast I guess.
>
> This terminology could use some further work I think though.
Thanks, let me know when you want me to look at something concrete.
>
>>>> Operation
>>>>
>>>> o First a generic comment that Trickle itself has some
>>>> operating
>>>> conditions which scopes its applicability, and it would
>>>> behove
>>>> this document to, in its own applicability statement,
>>>> call out
>>>> those.
>>> Added some comments regarding applicability.
>>
>> Better, but I would like to see that reflected also in a dedicated
>> applicability statement.
>
> I do not think we can actually provide so concrete applicability stmt as
> Trickle does though (e.g. RAM, LoC, etc) as it depends mostly on the protocol
> it runs on + network size + ..
I do not want to see RAM, LoC, etc. — and what you mentioned up above in the
email seems to be the right direction that you are going. One operating
condition for trickle to make sense is, for example, that you do not have a
continued flow of “changes to reflect” — hey, you say that somewhere in the
document already, that’s part of “where DNCP is applicable”. So I think that
in doing the other stuff you’re actually addressing this here.
>>>> Added protocol overview and made connection between trickle, merkle tree
>>> and requests more clear.
>> Indeed, and “merkle trees” disappeared and became hash trees somewhere along
>> the line ;)
>
> We were misusing the term actually; original Merkle tree was binary hash tree
> _only_, and while later on the term became synonymous with (N-ary) hash tree,
> when asked for Merkle references, just renaming it hash tree seemed to be the
> sensible choice as we were abusing the (original) definition.
Yup, and that’s quite fine.
>
>>>>
>>>> o Section 6.2:
>>>>
>>>> "An upper bound for the number of neighbors that are
>>>> allowed for a
>>>> (particular type of) link that an endpoint runs on
>>>> SHOULD be
>>>> provided by a DNCP profile, user configuration, or
>>>> some hardcoded
>>>> default in the implementation."
>>>>
>>>> A couple of things to that:
>>>> 1) Can you explain the parenthesis? What type of
>>>> link?
>>>> 2) How does "an endpoint runs on" a link?
>>>> 3) Why SHOULD?
>>>> 4) Is this specification seriously suggesting
>>>> "some hardcoded
>>>> default in the implementation" as a SHOULD?
>>>>
>>>> [I am tempted to upgrade this to a "Major issue" simply because
>>>> of 4) ]
>>> Clarified, the choice to use it is not really visible externally. Now
>>> the text has per multicast-enabled link type constraints, and also
>>> per-profile support for extension at all.
>>>
>>>
>>>>
>>>>
>>>> Also to 6.2, this particular optimization, do you have any
>>>> quantification of its actual benefit? What should I look for to
>>>> determine if this "optimization" yields a benefit or not? What
>>>> are
>>>> you trying to optimize? Over what link types does this function?
>>>> I am dubious that it "optimizes" much, if anything, across an
>>>> Ethernet, for example ...
>>> Oddly enough, most link-state routing protocols have this optimization.
>>> Added further description on why it is helpful.
>>>
>>
>> So, the things that you did to this, and the precious comment, helps. The
>> “designated router” (or equivalent/derivatives/*) mechanism is, as you point
>> out, well known and well used. I was yanking your chain a little bit here to
>> get, well, pretty much the explanation and discussion that you gave. Thank
>> you for that.
>>
>> Nit, though, just so that I feel useful in doing this:
>>
>> OLD:
>> MAY also be chosen at runtime. Main consideration when
>> selecting
>>
>> NEW:
>> MAY also be chosen at runtime. The main consideration when
>> selecting
>>
>>
>> But, good job here.
>
> Thanks :) Addressed.
;)
>
>>>> o Section 7.2.3, I worry when I see something like this:
>>>>
>>>> "The whole network should have roughly the same idea
>>>> about the time
>>>> since origination of any particular published state."
>>>>
>>>> What is the definition of "roughly"?
>>>> Is the "should" intentionally in non-caps?
>>>> What're the consequences if not?
>>>> [Note that trickle almost mechanically makes information
>>>> propagate
>>>> with non-trivial jitter across a network, so how do you ensure
>>>> this?]
>>> Clarified the paragraph, since the original text could be interpreted
>>> invertedly.
>> Another nit…
>>
>> Every node, including the originating one
>>
>> what is “the originating one”, is it “…including the node originating this
>> TLV”?
>>
>> Otherwise, yes to your clarification.
>
> ‘this TLV’ is also confusing, as you could say the TLV itself is sent by all
> nodes and as it is not passed verbatim (timestamp changes) it cannot be said
> to be originated by someone.
>
> Inserted “Every node, including the node publishing the node data,” for now.
>
I think that this works.
Recapitulating, I see basically two potential issues where we do not yet have
resolution:
o Versioning
o Address/Endpoint terminology
That’s already great progress.
For the former, either the proposal I made in this email (which included a
lunch appointment in 15 years time), or it may be one of those cases where we
will agree to disagree and have the RTG-ADs figure out what they want to take
it as.
For the latter, I’ll try to come up with something that might make sense (I may
meet Pierre tomorrow and bounce it around with him over coffee) and shoot back,
but anybody else with a proposal…please chip in.
Thanks for this exchange, it’s engaging and constructive and I can’t wait to
review -09 (regardless of what comes from the two above items).
Cheers,
Thomas
> Cheers,
>
> -Markus
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
