Subject: [babel] Suresh Krishnan's No Objection on charter-ietf-babel-00-02: (with COMMENT)

From: "Suresh Krishnan" <[email-masked]>
Date: Wed, 01 Jun 2016 18:34:42 -0700

Suresh Krishnan has entered the following ballot position for
charter-ietf-babel-00-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-babel/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* There is no mention of backward compatibility in the charter. Is the
"new" Babel intended to be backward compatible with the deployed
experimental version(s)? Might be worth noting either way.

* One of the potential (and I personally think one of the most important)
uses of Babel is as a routing protocol in homenets. Two of the things
that seem to be interesting improvements to Babel for this use case seem
to be a)self-configuration and b)source-specific routing. I do not see
either of them in the charter. I would have really liked to see something
in the charter to address these two issues.

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 2 Jun 2016 10:30:29 -0400

Hi,

On Wed, Jun 1, 2016 at 9:34 PM, Suresh Krishnan
<[email-masked]> wrote:
> ...

Well, it seems like all you would say is "Backwards compatibility with
deployed versions of Babel is desirable but not required." That can
certainly be added.

> in the charter to address these two issues.

HOMENET should be specifically reference as a WG with which to coordinate.

Based on IESG discussion that just occurred and HOMNET requirements,
auto-configuration should be added as a point. Not as clear about
source-specific routing.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Alia Atlas <[email-masked]>
Date: Thu, 2 Jun 2016 10:33:12 -0400

> auto-configuration should be added as a point. Not as clear about

Source-specific routing should be added as an item that the WG can do as a
secondary
focus - very similar to the multicast.

Thanks!
Alia

> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>

---

From: Dave Taht <[email-masked]>
Date: Thu, 2 Jun 2016 08:03:18 -0700

> https://datatracker.ietf.org/doc/charter-ietf-babel/

I tend to think making an entirely incompatible version would be a
kiss of death.

On the other hand, there are a metric ton of other problems I'd like
to be solving. (see below)

On the gripping hand, merely getting a "rip replacement" routinely
shipping and regularly available would be nice.

> in the charter to address these two issues.

a) self-configuration should be hardened, agreed. I saw an interesting
new approach in bmx7 the other day...

http://bmx6.net/news/22

...

Not entirely relevant to the formation of this wg, but stuff I wish
had homes elsewhere (do they? most of my issues tend to cross layers
these days):

b)  I'd like to see source specific routing widely available in all
routing protocols. I'd even like to see an extension to RA.

c) It is not just a homenet thing to want ethernet, homeplug, wifi,
5g, 6lopan, etc, interoperating well with different isps and devices.

I'd like to see more interoperable interfaces to other link layers
(6lowpan/threads, usb, can, 802.11ad, 5g, homeplug, etc), be they
routing, failure mode detection, address assignment, security, or
service advertisement.

In particular, I could see usb-c one day becoming a short haul
ethernet replacement if it spoke IP well and universally, and the tv
becoming the network center of the home... I don't know where
HDMI-ethernet went wrong...

(I routinely use babel to route between wifi, ethernet, and usbnet
"gadget"s today - modern hackerboards like the pi, and getchip.com
etc, all have this basic support, and many hackerboards are arriving
that speak usb and wifi only - and lack ethernet. )

IP over usb is way better than IP over wifi.

( side note: trying to nail down an interesting problem on usbnet/wifi
here: http://blog.cerowrt.org/post/babel_half_fail/ )

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 02 Jun 2016 20:33:23 +0200

> I tend to think making an entirely incompatible version would be a

Not necessarily if the implementation speaks both versions, at least
initially.  (To be clear -- I sort of agree with you, but try to keep an
open mind.)

(OTOH, I'm increasingly thinking I'm going to redo source-specific routing
in an inompatible manner.  I'll write up my thoughts on babel-users.)

> shipping and regularly available would be nice.

Yes.  Let's be careful to keep the spec simple.  (Defined as "fits in the
head of a third year student without swapping".)

> a) self-configuration should be hardened, agreed.

I'm surprised to hear that from you.  You've been running a production
Babel network for years, Dave, and providing me with useful bug reports,
but I don't recall you having issues with router-id collisions.  (See my
reply to Tony.)

> routing protocols. I'd even like to see an extension to RA.

Rtgwg, I believe.  I'm pretty confident the RA extension will happen.

> routing, failure mode detection, address assignment, security, or

I'm pessimistic.

-- Juliusz

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 3 Jun 2016 03:39:54 +0000

Hi Don/Alia,

On 06/02/2016 10:33 AM, Alia Atlas wrote:
>
> On Thu, Jun 2, 2016 at 10:30 AM, Donald Eastlake <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     <[email-masked] <mailto:[email-masked]>> wrote:

That sounds good to me if there is energy in the community to do that.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 3 Jun 2016 03:47:27 +0000

Hi Dave,

 > had homes elsewhere (do they? most of my issues tend to cross layers

Interesting read. Thanks for that pointer.

 > routing protocols. I'd even like to see an extension to RA.

Something like this?

https://tools.ietf.org/html/draft-pfister-6man-sadr-ra-01

 > that speak usb and wifi only - and lack ethernet. )

Cool.

Thanks
Suresh

---

From: Dave Taht <[email-masked]>
Date: Sat, 4 Jun 2016 08:15:23 -0700

> https://tools.ietf.org/html/draft-pfister-6man-sadr-ra-01

Is the expired state of that draft an indicator that it died?

Getting an implementation that worked did strike me as very little
code, which I'd gladly patch in if it existed somewhere.

---

From: Pierre Pfister <[email-masked]>
Date: Sun, 5 Jun 2016 11:27:53 +0200

Hello Dave,

> Le 4 juin 2016 à 17:15, Dave Taht <[email-masked]> a écrit :
> 

I did implemented it, and it was very little changes in the kernel (<100 LoC).
I can try to dig that out if it helps you.

This draft started as an alternative to https://www.ietf.org/archive/id/draft-sarikaya-6man-sadr-ra-03.txt.
But I received push-backs due to on-wire changes in my proposal.
6man chairs asked Brian to propose a solution without on-wire changes: https://www.ietf.org/proceedings/93/slides/slides-93-6man-6.pdf
Then, Fred accepted to draft such an option, which has now become this: https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-06

So I guess unless the working group comes to a conclusion that a protocol change is required in order to address the problem, the draft is effectively dead.

Cheers,

- Pierre

> http://blog.cerowrt.org <http://blog.cerowrt.org/>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 05 Jun 2016 16:02:48 +0200

> experimental version(s)? Might be worth noting either way.

I've been refraining from answering this point, since I wanted to hear
people's opinions.  I guess the discussion has died now.

The answer is -- we haven't decided yet.  On the one hand, there are some
improvements that we could make if we decide to be incompatible (notably
adding a mandatory bit to sub-TLVs and making metrics wider -- they're
currently 16 bits).  On the other hand, making an incompatible version
will be an inconvenience for our current users (Dave goes so far as to
speak of a "kiss of death"), and runs the risk of not being able to decide
on the right bikeshed colour.

My current opinion -- likely to change as we discuss stuff some more -- is
that the base protocol should remain compatible, but we'll want to make an
incompatible (and much better) encoding for the source-specific routing
extension.  However, I am listening to people who think otherwise, especially
if they have implementation experience.

Please note that keeping the packet format compatible doesn't mean we
cannot make changes to the protocol that are technically incompatible --
we can tighten the specification, and we can remove undesirable features
as long as we mark the removed codepoints as reserved for backwards
compatibility.  (For example, I'm considering removing AE 0, but
implementations will be free to continue implementing it indefinitely.)

-- Juliusz

---

From: Denis Ovsienko <[email-masked]>
Date: Sun, 05 Jun 2016 18:18:25 +0100

---- On Sun, 05 Jun 2016 15:02:48 +0100 Juliusz Chroboczek  wrote ---- 
>people's opinions. I guess the discussion has died now. 
[...]

Hello all.

That's an important question and I have been considering this for a while too. Not as much expressively but I am inclined in roughly the same direction as Dave (maybe learned similar lessons). Running code is important, and same important is to keep the right amount of running code in the scope.

In this sense it would seem reasonable for the WG to start with a compatible version and be able to use the working codebase. At the same time, it would make sense to start a list of incompatible changes to consider for Babel version 3 (with the stated impact and gain of each change). Then a few months later it would be easier to see the expected balance of the switch and the amount of work required and to make further plans based on that.

I would have a small encoding change suggestion for that list too. Nobody has to make it in Babel v3 and nobody has to specify Babel version 3 ASAP, but I could explain and we could discuss (time permitting).

-- 
    Denis Ovsienko

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 05 Jun 2016 23:36:52 +0200

> That's an important question and I have been considering this for
> a while too. Not as much expressively but I am inclined in roughly the
> same direction as Dave (maybe learned similar lessons).

Noted.

> Running code is important, and same important is to keep the right
> amount of running code in the scope.

We're not going to standardise anything without implementation experience.
As soon as we start making changes, I branch babeld and we implement
anything that we're considering for standardisation.  (This includes you
and me, but also Matthieu and Toke, and hopefully a number of people who
lurk on this list and who used to help with babeld before they sold their
souls to the private sector.)

Most IETF WGs are doing their homework, and implementing everything that
they consider for standardisation.  Some other WGs have been standardising
stuff that's never been implemented, with the results that you imagine.
Let's be very vigilant, and make sure we belong to the former category.

-- Juliusz