Re: [babel] Summary of the top-secret unicast Hellos meeting

[David Schinazi <[e-mail]>]

To clarify what I think Juliusz means when he says Unicast Hellos are "optional":

- parsing both unicast and multicast (and the UNICAST flag) is a MUST
- however, how nodes reacts to these Hellos is up to implementations

(Even in 6126 a node can decide to parse a Multicast Hello and
set a cost of infinity or even ignore that neighbor)

So implementations need to be aware of both kinds of hellos, but
they do not need to form neighbor relationships with all of them.

David


> On Jul 19, 2017, at 18:10, Juliusz Chroboczek <[e-mail]> wrote:
> 
> Dear all,
> 
> TL;DR version: we keep unicast Hellos but make them optional.  We write
> this up in the rfc6126bis draft, and see how well it reads.  We then
> request feedback on the list.
> 
> You may now skip the rest of this mail.
> 
> First, some background.  Hellos in Babel carry a monotonically increasing
> sequence number (seqno) which must be synchronised between sender and
> receiver.  Since there is a single seqno per outgoing interface, every
> Hello MUST be sent to all neighbours on each interface -- either over
> multicast (RFC 6126) or over exhaustive unicast (allowed in rfc6126bis,
> insight due to Margaret).  There is some desire -- expressed most vocally
> by David and Toke -- to send Hellos over unicast to different neighbours
> at different times, which requires either getting rid of the seqno or
> adding a per-neighbour outgoing counter in addition to the per-interface
> counter.
> 
> Russ White sent me a series of (private) mails that gave some insight into
> the issue.  In general, the Babel protocol specifies only very loose
> coupling between sender and receiver, which makes the protocol easy to
> evolve in a compatible manner.  Not so with the Hello sub-protocol: the
> sender and receiver seqnos are tightly coupled, which makes this
> sub-protocol difficult to evolve.  I think this analysis is spot on.
> 
> We started the meeting with me giving some background into the problem
> (roughly speaking the two paragraphs above).  We then did some
> brainstorming about what solutions we see: a new type of "unicast" Hello
> (David and Toke's proposal, in the current version of the draft).  A new
> type of seqno-less Hello (my proposal, but it has a serious flaw -- Hello
> and seqno-less Hello would support different sets of sub-TLVs).  Removing
> the seqno from Hellos and bumping the protocol version number to 3
> (Matthieu's proposal, rejected since we're happy with version 2).  As well
> as some more convoluted ideas (names of the authors withheld in order to
> protect the guilty, but I'll be happy to gossip over a beer).
> 
> During this discussion, there were a few interesting insights.  Margaret
> expressed some doubts about the usefulness of different Hello intervals
> for different neighbours.  She noted that our intuition that one should
> reduce the Hello interval for marginal neighbours might be incorrect:
> quite the opposite, since with a shorter interval short-term outages might
> be spuriously detected as link drops.  Agreed, although the length of the
> window is not necessarily related to the interval.  More experimentation
> and experience is needed.
> 
> David expressed some ideas about using driver data instead of Hello drop
> rate.  We agreed that this might be mentioned in Appendix C, but is only
> reasonable for implementors that control the whole OS.  (I wonder who that
> can be.)
> 
> Matthieu suggests that we might want to test both multicast and unicast
> reachability before using a neighbour for routing, since unicast-only link
> failures happen sometimes.  David noticied that IHU does that.  Matthieu
> noticed that IHU can be sent over multicast too (and is in the reference
> implementation, ndlr).
> 
> IHU with AE 0 is used by David over unicast only.  He's in favour of
> leaving it in the protocol, but forbidding it for multicast.  I disagree,
> I'll write that up on the list.
> 
> At this point, the discussion was moving away from the Unicast hellos, so
> we decided that we don't have an idea that is significantly better than
> the current David-Toke proposal (there was one dissenting voice).  We went
> back to my mail of yesterday evening, and there was clear consensus on the
> following two points:
> 
>  - we leave unicast Hellos in (no to proposal 1);
>  - we don't delegate them to a future ducument (no to proposal 2).
> 
> Right now, the document contains a mild contradiction: you MUST be able to
> parse unicast Hellos, but you are allowed to essentially ignore them.  We
> have agreed that we're going to tweak the document to make unicast Hellos
> more optional, and see whether we can make it so it gives more convincing
> advice to the implementor.
> 
> Therefore, we'll try to write up proposal 3 -- keep the packet format, but
> make it somewhat more optional.  The actual protocol will remain mostly
> unchanges, only the level of MUST-ness will shift.
> 
> Thanks to everyone,
> 
> -- Juliusz
> 
> _______________________________________________
> babel mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/babel