On 23.2.2015, at 17.24, Juliusz Chroboczek <[email protected]>
wrote:
>> post MTU, or in secure mode, it should just use the Short one (which is
>> of fixed length).
> Ok. So I send multicast SNS. I receive NSR. I'm supposed to send LSR,
> right? But it doesn't fit in maximum packet size, even with fragmentation.
>
> RFC 2460, Section 5:
>
> A node must be able to accept a fragmented packet that, after
> reassembly, is as large as 1500 octets. A node is permitted to
> accept fragmented packets that reassemble to more than 1500 octets.
> An upper-layer protocol or application that depends on IPv6
> fragmentation to send packets larger than the MTU of a path should
> not send packets larger than 1500 octets unless it has assurance that
> the destination is capable of reassembling packets of that larger
> size.
I guess this is another MUST to be added to HNCP text (DNCP itself is not
IPv6-specific as such).
I am not convinced by the trend to add fragmentation to every protocol on top
of IP{v4,v6} but can be convinced otherwise of course given good arguments. At
least in case of HNCP as it works on link-local level only, I think saying you
MUST have sane IP stack on both nodes is not overreaching it as there are no
middleboxes to worry about.
>> Current assumption is that sane set of node data fits inside one
>> (potentially fragmented) IPv6 packet (non-jumbogram), essentially
>> limiting the maximum size to <64kb.
> You cannot count on that. See above.
I consider it documentation error, see above :)
>>> What should I do if I receive an unknown TLV? I assume I should silently
>>> ignore it if it's inside a Data TLV, and include it in my database and
>>> flood it if it’s within a Data TLV, right?
>> Right.
> Please make that very clear. Implementors will get it wrong, and we'll
> find ourselves unable to extend the protocol.
Ok, I will add one more MUST (although reading the text, I thought it obvious
already from the context but guess not).
+ Whole “node data" is owned by the node that
+ publishes it, and it MUST be passed along as-is, including TLVs
+ unknown to the forwarder.
>>> Which messages are allowed to contain extra TLVs? For example, what
>>> should I do if I receive a Long Network State Update with a bunch of
>>> unknown TLVs interleaved with the Node State TLVs?
>> Any of them. The messages are defined just by the MUST be present TLVs.
> Again, please make this very clear. In particular, make it clear that
> upon encountering an unknown TLV, the rest of the packet must be processed
> as usual. (The other possible choice is that the whole rest of the packet
> is ignored.)
<t>DNCP profiles MAY add additional TLVs to the message specified
- here, or even define additional messages as needed.</t>
+ here, or even define additional messages as needed. TLVs not
+ recognized by the receiver MUST be ignored. </t>
>>> There's a single connection for all neighbours on a given interface,
>>> right? Why not call that an Interface, then?
>> In case of HNCP, this is true, as it has connection=(link-local IPv6
>> UDP-using) interface. In DNCP, a connection may be just e.g. one unicast
>> endpoint you want to talk with over the internet.
> I see. I still dislike the term of "connection", which seems to imply
> a point-to-point thing. Ideas?
Not from me; we had relatively long (and fruitless) internal discussion on this
in November IIRC.
>>> 7. Neighbor graph
>>>
>>> The notion of "neighbor graph" suddenly appears in Section 5.4. It's
>>> pretty obvious what you mean, but this should be precisely defined
>>> somewhere.
>> The later traversing definition more or less describes what it ‘is’; any
>> idea of what a good definition would look like?
> Actually, looking at it again, I'm not sure I know what is the neighbour
> graph. It's the directed graph defined by all neighbour TLVs, or the
> undirected graph that you get after removing unidirectional neighbours?
> I assume the latter.
The latter. Edited text a bit in few places, dunno if it really helped :)
-Markus
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
