Subject: [babel] [PATCH 1/4] address IETF-97 slides section I point 1

From: Denis Ovsienko <[email-masked]>
Date: Sun, 11 Dec 2016 23:33:03 +0000

"Some of the thinking made in Appendix A.1 looks normative and could
make Section 3 (Protocol Operation) more complete if moved there."

This change in the middle of "Reverse Reachability Detection" adds one
specific piece that was missing: the document did specify updating and
flushing of a neighbour entry, now it also specifies initialization.
---
 draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml b/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml
index bac204b..9fa18c4 100644
--- a/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml
+++ b/draft-ietf-babel-rfc6126bis/draft-ietf-babel-rfc6126bis.xml
@@ -703,7 +703,9 @@ decreased at any time; it SHOULD NOT be increased, except immediately
 before sending a Hello packet.  (Equivalently, a node SHOULD send an
 unscheduled Hello immediately after increasing its Hello interval.)</t>
 
-<t>How to deal with received Hello TLVs and what statistics to maintain
+<t>A node that receives a Hello TLV from an unknown neighbour creates a new
+entry in the neighbour table and sets its txcost to infinity. How to deal
+with the received Hello TLVs further and what statistics to maintain
 are considered local implementation matters; typically, a node will
 maintain some sort of history of recently received Hellos.  A possible
 algorithm is described in <xref target="hello-history"/>.</t>
-- 
2.7.4

-- 
    Denis Ovsienko

---

From: David Schinazi <[email-masked]>
Date: Mon, 12 Dec 2016 13:24:05 -0800

Denis,

As discussed in the other thread (patch 2/4), I believe this change
unnecessarily constrains the protocol. The existence of a neighbor table
is purely an implementation detail that I'd rather keep in an appendix.

David

> On Dec 11, 2016, at 15:33, Denis Ovsienko <[email-masked]> wrote:
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

---

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

> is purely an implementation detail that I'd rather keep in an appendix.

Well, yes and no.  The protocol is described in terms of a set of
conceptual data structures, and the neighbour table is described in
Section 3.2.3.  OTOH, the data structures are conceptual -- you're welcome
to use a different set of data structures as long as they achieve the same
result.

There's a number of reasonable data structures for describing Babel (for
example pybabel uses two route tables instead of a single table with
a boolean selected flag, while my implementation uses a set of linked
lists with the selected route being at the head), but I don't see how you
can get away without a neighbours table.

I agree with you on all of your remaining points.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Tue, 13 Dec 2016 16:15:10 -0800

Agreed. I've reread the section since and am fine with specifying how to
initialize the neighbor table entry.

David

> On Dec 13, 2016, at 15:37, Juliusz Chroboczek <[email-masked]> wrote:
>