On 1.7.2015 14.26, Juliusz Chroboczek wrote:
### NODE-ENDPOINT is stateful
NODE-ENDPOINT identifies the sender of this packet, and applies to all
TLVs in this packet. The current specification implies that the
NODE-ENDPOINT may appear anywhere in the packet, which would force the
receiver to make two passes over the packet.
Not really. In the current specified processing flow, the only dependency
on endpoint is with the Network State TLV (and it's handling of consistent
<> inconsistent per neighbor).
I may be missing something, but I suspect you're assuming that the neighbour
(peer) table is indexed by addresses; in my implementation, it is indexed
by (id, eid, lid) triples, hence I cannot access my per-neighbour data
structure until I've learned your (id, eid).
If indexing by (interface, address) pair is the only legal implementation,
you'll need to make it explicit in the draft. (What I'm doing here is
technically known as blackmail.)
In stream case, you may need to associate a connection with the remote
peer (to store the remote endpoint id + node id) as it may not be
available during TLV processing even if it is 'assumed' to be present.
Otherwise, not really.
I'll bite and look at TLV processing:
- RNetS: no need (local state response)
- RNodeS: no need (local state response)
- Endpoint: depends on if we know the (peer, endpoint) already;
unknown:
* add peer (unicast), send RNetS (multicast)
known:
* update last contact (unicast)
- NetS: need (possibly with delay, to update Trickle state match; we do
Trickle state update last so ordering does not matter)
- NodeS: no need (local state update, regardless of where it comes from)
Do you have some other TLVs and-or different interpretation on how the
individual TLVs are processed?
- MUST be before Network State TLV (I am fine with this, it removes one
flag from my current implementation's one-pass parsing)
This will force me to change my implementation -- I'm currently not
sending a REQ-NODE-STATE unless I've seen an endpoint, so as to avoid
sending it to passive observers.
Please let me know if you prefer me to change my implementation, or
whether you're willing to add MUST NODE-ENDPOINT before NODE-STATE.
I do not know why you need it with NodeS, it should not be needed there
as far as I understand it.
### NODE-ENDPOINT is underspecified
It is not clear whether NODE-ENDPOINT is required in all packets,
Current text says MUST all [...] The current spec is simpler, so
I prefer that, and rather just fix implementations.
I strongly disagree. Sending NODE-ENDPOINT has the side effect of storing
a neighbour in the peer, which is not something a purely passive observer
should be doing. If a node is not sending NETWORK- or NODE-STATE, it
shouldn't even need to choose an id -- it should be allowed to make
a simple request/response transaction that is completely stateless for the
responder.
It is MUST if and only if you desire bidirectional peering relationship
currently. So if you don't, you shouldn't need to still send it. Perhaps
the text could be clarified more.
I suggest MUST for NETWORK-STATE, and "SHOULD if available" for all others.
(And of course MUST for NODE-STATE if you make the change suggested above.)
See above. Why do you need it with NodeS?
### Keep-alive intervals are flooded
[...]
We prototyped both, but essentially global state is cheaper in a small
network than constant payloads on the link.
You've almost convinced me, so I'll just note that the same issue exists
with the NODE-ADDRESS TLV in HNCP -- there's no reason to flood this
information beyond the local link. In that case, the amount of state
spuriously flooded could be moderately large (24 bytes per router per
attached link), which argues in favour of a mechanism that allows
publishing data that doesn't go beyond the local links.
As you say, not sure it's worth the complexity.
For SD purposes, we need at least 1 address per router. However, you are
correct, that _all_ addresses are not really necessarily needed (as
noted elsewhere). Perhaps we should just move this to a SHOULD
(+~SLAAC+ND backup), and then MUST have at least 1 address published in
the SD section if it is supported.
Protocol dynamics
-----------------
### Need to check sender
### Not clear when multicasts and unsolicited packets can be sent
I've reordered your replies to these two parts.
I do not think it is unclear on MUST reply via unicast. How would you
prefer it written out?
I would like the licence to reply over multicast, at least in some cases.
For example, if I've just republished my state, all of my neighbours are
going to be interested in my new state, am I allowed to reply over
multicast once and for all? (Of course, I can send a gratuitious multicast
NODE-STATE, but the new NETWORK-STATE may already have triggered a bunch
of requests, and I'd like to avoid having to reply to those individually.)
Another optimisation would be sending the "long" NETWORK-STATE over
multicast if I've buffered multiple requests over the same interface.
I find this problematic as then we get matrix of
- profile
- implementation
- security mode (=nothing valuable over multicast, please)
- .. and few other parameters
deciding whether or not a) what you sent is valid, and as a result, b)
whether the network converges given multiple interpretations of the rules.
Spirit of the current spec _would_ allow for e.g. doing multicast reply
by default, but probabilistically (e.g. 20%) or after awhile (if you are
willing to spend the resources to keep track) responding also via
unicast - MUST _eventually_ reply is there for that reason - so that
nodes that are not happy with multicast would still converge eventually,
just slower.
Better descriptions on how to convey the idea would be welcome, as usual.
The distinction is needed (I think); otherwise multicasting 'something'
(=something completely braindead and-or topology graph-wise
unidirectionally reachable now) would still be kept danngling as long as
transmissions continue.
Epiphany! The protocol may keep unidirectional links indefinitely, but
only if the network states are consistent on both sides (Section 6.1.4).
Which doesn't harm, since (i) the states are consistent, and (ii) the link
will be purged by the silly walk. That's really smart, and really subtle.
I think that's subtle enough to be explicitly spelled out in the document.
Markus, for the sake of minimality, I would like you to work out exactly
which packets MUST be sent over unicast, and specify the exact minimal
set. You're welcome to SHOULD the others.
I am worried about state space explosion in drafts (and our heads). Let
me know if you it is still necessary given the above description on why
MUST unicast does not kill most multicast dreams ;)
Cheers,
-Markus
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
