> (Argh, kilometer long cc list, sorry guys in advance..) Dropping everyone and his brother too, leaving Homenet and Alia, adding babel-users and Stephen.
> Sadly enough the more flexible/less code footprint _given system-wide > IPsec_ approach of OSPFv3 turned out not to be popular. It allowed us to > secure Babel with just few lines of changes to one script in the hnetd > implementation, which was neat, but.. :-) Hmm, if you're using static keying, you're vulnerable to replay. Does that mean I should port the replay protection bits from RFC 7298 to the reference implementation? They don't frighten me as much as the crypto bits. > I am not very fond of making any MUST metric functions either. However, > what I _would_ like to see is some guidance on metrics ranges that > should be used and how the combination should approximately work best > (remember ‘pybabel’s metric=1 + combination using + favors it too much’ > email). Perhaps this could be also just in an appendix. Point taken. >> There is only one mechanism in the base spec that is not currently used by >> implementations -- it's the reliable transport building block defined in >> Section 3.3. It has very low cost (20 lines of code or so in the >> C version), > I am not very fond of it, as I do not see much of a justification for it > given the goal of minimality. See the discussion in Section 3.7.2 of RFC 6126. I've been planning to implement that, to see how much it improves behaviour in sparse wireless meshes. > E.g. on point-to-point link (or one with few routers), you could send > stuff very rarely and just use that ack feature to make sure the other > end is aware of the current state Hmm... have you noticed the (optional) receiver-driven scheme described in Section 3.8.2.3? But yes, you're right, although fine-tuning the details of your scheme might not be quite obvious. > I only wonder about the padding TLVs/sub-TLVs I don't expect anyone to use padding for alignment. But I'm fond of PAD1 and PADN TLVs, since they don't cost much and often turn out to be useful for various reasons. For example, the Babel-RTT extension puts a PADN sub-TLV at the place where a timestamp will go; then it applies jitter to the outgoing packet, and patches it with a timestamp at the very last moment. If the timestamping fails for some reason, the packet can still go out -- the PADN will be ignored by the receiver. Look, Ma, no complex error handling and no packet drops. (Credit to Baptiste Jonglez.) Similarly, suppose you wanted to do MTU probing a la OSPF (or is it IS-IS?), or wanted to evaluate packet loss for full-size frames only. In either case, PADN your Hellos to full MTU, and you're done. > Especially given multicast-using (default) nature of the protocol, I am > fond of _a_ solution that fits as much as possible in one MTU packet per > interval; therefore, more costly format would essentially behave worse > for networks above certain size (in terms of # of total routes mostly). I agree. Still, it might be worthwile to have an expert pore over the packet format, and see how much he shakes his head. -- Juliusz _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
