Subject: [babel] babel - New Meeting Session Request for IETF 97

From: "\"IETF Meeting Session Request Tool\"" <[email-masked]>
Date: Mon, 12 Sep 2016 08:01:36 -0700

A new meeting session request has just been submitted by Donald E. Eastlake 3rd, a Chair of the babel working group.

---------------------------------------------------------
Working Group Name: Babel routing protocol
Area Name: Routing Area
Session Requester: Donald Eastlake

Number of Sessions: 1
Length of Session(s):  1.5 Hours
Number of Attendees: 65
Conflicts to Avoid: 
 First Priority: manet ospf homenet trill saag lpwan isis idr rtgwg 6man v6ops i2rs netmod netconf
 Second Priority: dnsop dnssd

Special Requests:
  
---------------------------------------------------------

---

From: Denis Ovsienko <[email-masked]>
Date: Mon, 26 Sep 2016 22:56:41 +0100

---- On Mon, 12 Sep 2016 16:01:36 +0100 "IETF Meeting Session Request Tool"  wrote ---- 
>A new meeting session request has just been submitted by Donald E. Eastlake 3rd, a Chair of the babel working group. 

Hello group.

I would like to progress the suggested change to spell the neighbour state machine and its valid transitions in RFC 6126-bis.

Besides being useful on its own this addition should make it one step closer to the RFC 7298 problem solution as discussed before. If it would be notably better to review the problem in person at IETF, please let me know soonest possible so I can prepare some slides and try to book the trip. Otherwise I would be equally happy with a diff to the .xml file and a mailing list discussion. Let's just try to see what works better so long as it's not too late to make plans.

-- 
    Denis Ovsienko

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 27 Sep 2016 00:50:49 +0200

> I would like to progress the suggested change to spell the neighbour
> state machine and its valid transitions in RFC 6126-bis.

Could you please clarify?  Babel doesn't have a state machine -- it's
described as a stateless protocol, with received TLVs causing changes to
the data structures and scheduling actions to happen.  It's not at all
clear to me whether it can be described as a finite state automaton (I
strongly doubt it).

> Otherwise I would be equally happy with a diff to the .xml file and
> a mailing list discussion.

Sorry for my silence -- I've been lecuting 18 hours a week.  My teaching
load drops to 12 hours this week, I'll hopefully find some energy to make
a github project and set up things up.

> Let's just try to see what works better so long as it's not too late to
> make plans.

I will not be going to Seoul, sorry, too much teaching.  I'll definitely
be getting down to work as soon as I recover from September.  (I'm not
complaining, mind you -- September at university is a lot of fun, but it's
also very hard work).

Sorry for that,

-- Juliusz

---

From: Denis Ovsienko <[email-masked]>
Date: Tue, 27 Sep 2016 22:40:12 +0100

---- On Mon, 26 Sep 2016 23:50:49 +0100 Juliusz Chroboczek  wrote ---- 
>clear to me whether it can be described as a finite state automaton (I 

One specific part of the protocol is already a finite automata. An AckReq, Update, RouteReq or SeqnoReq TLV cannot be actioned before the neighbour has a 2-way connectivity (IHU TLV), which implies a 1-way connectivity (Hello TLV). Spelling the already existing transitions through a FSM is what I mean here and in the previous messages.

>a github project and set up things up. 

I was going to ask exactly that.

-- 
    Denis Ovsienko