[Babel-users] [homenet] Selecting a routing protocol for HOMENET

[Juliusz Chroboczek]

> (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