Subject: [babel] Discussion about Denis' comments: conclusion?

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 14 Dec 2016 03:09:39 +0100

So, my reading of this discussion is that 3.4.1 and 3.4.2 must be
rewritten.  In addition to that, we need to decide between the following:

  (1) a neighbour entry MUST be created upon receiving any kind of packet;

or

  (2) a neighbour entry MUST be created upon receiving a Hello, MAY be
      created upon receiving an IHU;

or

  (3) a neighbour entry MUST be created upon receiving a Hello, and MAY be
      created upon receiving any kind of packet;

or

  (4) a neighbour entry MAY be created upon receiving any kind of packet.

My preference is (3), which is not too restrictive while guaranteeing that
an entry will be created at some point.  I find (4) tempting, since it is
the least restrictive, but it requires additional language to ensure that
an entry is created at some point, and I'm not sure what it is.  (Or
perhaps it doesn't -- after all, whether to speak to a given neighbour is
an implementation detail.)

None of the above fix Denis' problem, which should be handled in the HMAC
protocol, not in the core protocol.  I think Denis should add
a requirement that says that a packet fails validation unless the
neighbour has sent something in the last something, but I'm not clear
about the details.

Are we agreed?

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Tue, 13 Dec 2016 19:25:19 -0800

I agree with the spirit of what Juliusz says.
Regarding actual phrasing, how about the following middle ground:

(5) A neighbour entry MAY be created upon receiving any kind of packet.
If an implementation wishes to exchange routing information with a given
peer, it MUST create a neighbour entry upon receiving a Hello, if a 
corresponding entry does not already exist.

But that starts sounding complicated and I really don't feel strongly
about the actual wording as long as I'm not required to ignore packets
received before the first Hello. And now that I think about it in those terms,
how about:

(6) A neighbour entry MAY be created upon receiving any kind of packet.
An implementation MAY choose to ignore any packet received from a peer
before a Hello packet, and create the neighbour entry upon receiving that
first Hello.

David

> On Dec 13, 2016, at 18:09, Juliusz Chroboczek <[email-masked]> wrote:
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

---

From: [email-masked]
Date: Wed, 14 Dec 2016 14:35:00 +0800

I prefer (3) too. I think that the neighbour entry is very useful for 
debugging whenever any packet is received.
If it is better that use “SHOULD” replace “MAY”?
(3) a neighbour entry MUST be created upon receiving a Hello, and SHOULD 
be created upon receiving any kind of packet;

Sandy

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 14 Dec 2016 16:13:46 +0900

> On 14.12.2016, at 12.25, David Schinazi <[email-masked]> wrote:

I like 6, as forcing (MUST) neighbor in any case seems unneccessary (you may e.g. only care about subset of nodes for some reason that share the link). And this (6) is bit more prescriptive than Juliusz' (4) which I also like.

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 14 Dec 2016 14:35:16 +0100

Okay, perhaps we're doing it wrong.  Why not assume that the reader is of
average intelligence or higher, and not spelling out everything?

    When to create a neighbour entry for a given neighbour is a matter of
    implementation policy, as long as a neighbour entry is eventually
    created for any neighbour with which the current node wishes to
    exchange routing information.  A simple strategy is to create
    a neighbour entry whenever the current node receives a packet from
    a new neighbour, or at least whenever it receives a Hello TLV.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 14 Dec 2016 14:45:12 +0100

>     a new neighbour, or at least whenever it receives a Hello TLV.

And if we want to be wholly explicit, et the risk of insulting the
reader's intelligence:

    An implementation MAY choose to drop all packets from a given
    neighbour until it decides to create an entry in the neighbours table.
    Protocol extensions may want to put further restrictions on when
    a neighbour entry is created, notably for security reasons.

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 14 Dec 2016 08:22:20 -0800

>>     a new neighbour, or at least whenever it receives a Hello TLV.

I like this one. Or alternatively (3) above.

>     a neighbour entry is created, notably for security reasons.

I am generally of the opinion that we should keep the number of insults
to the reader's intelligence to a reasonable number in a document such
as this...

-Toke