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

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 19 Jul 2017 18:10:46 +0200

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 19 Jul 2017 19:05:12 +0200

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 <[email-masked]> wrote:
> 
> Dear all,
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 20 Jul 2017 15:27:37 +0200

> request feedback on the list.

I have updated my unicast hello implementation to comply with what is
currently in rfc6126bis (I think). Code (still untested) here:
https://github.com/tohojo/bird/tree/babel-unicast

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 20 Jul 2017 16:12:17 +0200

> https://github.com/tohojo/bird/tree/babel-unicast

Looks good to me.  Encapsulating the Hello history into a struct is a good
idea, I might use the same factoring for the specification text.

Could you please explain ifa->cf->unicast_mode?

Any ideas about improving link quality estimation would be useful.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 20 Jul 2017 17:14:14 +0200

> https://github.com/tohojo/bird/tree/babel-unicast

In case you want to test interop, see the branch rfc6126bis of the babeld
repository.  Right now it's ignoring unicast Hellos, it should be using
them within a few minutes.

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 20 Jul 2017 18:06:47 +0200

>idea, I might use the same factoring for the specification text.

Yeah, that could probably work for text as well 

>Could you please explain ifa->cf->unicast_mode?

That's the unicast configuration setting. At present, it's just a binary setting (called 'prefer unicast'), which will enable the sending of unicast hellos, and switch to using the unicast hello history to compute the cost to any peer that sends them.

I'm planning to expand the option to also support disabling multicast entirely, and to support specifying unicast peers in the configuration file. I have also yet to add support for sending other TLVs as unicast.

>Any ideas about improving link quality estimation would be useful.

Yeah, haven't gotten to that part yet...

-Toke