>> ### 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.) > - 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. >> ### 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. 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.) >> ### Fragmentation is specified at the TLV level > I am essentially for removing whole fragmentation scheme [...] especially > as nobody has implemented it I strongly agree. Working code and all that. >> ### 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. >> 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. > 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. -- Juliusz _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
