[Babel-users] ANNOUNCE: babeld-1.8.1

[Juliusz Chroboczek]

Dear all,

Version 1.8.1 of babeld, the Babel routing daemon, is available from

https://www.irif.fr/~jch//software/files/babeld-1.8.1.tar.gz
https://www.irif.fr/~jch//software/files/babeld-1.8.1.tar.gz.asc

This release makes two important changes, and upgrading is strongly
recommended.

First of all, it properly parses and acts upon the new kinds of messages
allowed by RFC 6126bis, the upcoming version of the Babel specification.
However, it doesn't send any of the new messages, so it should be
perfectly safe to upgrade.  In particular, it still uses the old format
for source-specific routing.

Second, it fixes a long-standing bug that would delay convergence in some
cases.  You should find convergence times much improved, at the cost of
a small increase in control traffic.

There's also a fix for point-to-point interfaces under Linux, babeld shold
work fine over wireguard now.

Enjoy,

-- Juliusz

7 April 2018: babeld-1.8.1

  * Implemented parsing of mandatory sub-TLVs and unicast and unscheduled
Hellos.  This makes this version comply with RFC 6126bis.  However, we
don't send any of these yet, so this version remains compatible with
RFC 6126.
  * Fixed a bug that prevented us from sending requests after we lose
a route.  This makes convergence much faster in some cases, at the
cost of slightly increased traffic.
  * Fixed interface addresses on some kinds of point-to-point links.
  * The keep-unfeasible (-u) option has been removed, this is now the
default behaviour.




pgpT0s8AKmku1.pgp
Description: OpenPGP Digital Signature
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Babel mesh in the skies :)

[Juliusz Chroboczek]

> you may find this video interesting:
> https://youtu.be/agPdI7cY5eU

Cool.  I see some more info on https://meshpoint.me/

> We are using Babel routing for MeshPoint, and we would like to become
> a more active contributors to Babel project.

Let's try to arrange to meet and have a chat.  I'll get in touch with you
by private mail.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Fastest convergence possible

[Juliusz Chroboczek]

> Presently, I'm starting my babeld instances in 2.1 seconds intervals and
> then wait 25 seconds for convergence.

That's not what Babel is optimised for.

Babel is built around the assumption that links are unstable.  A Babel
node keeps a fair amount of state so it can reroute quickly in the case of
a link failure.

When you reboot a Babel node, it has no state, and therefore needs to
rebuild all of its state from scratch.  You will see that if you run
a Babel network then start breaking your tunnels -- babeld should reroute
around failure within milliseconds (after the failure is detected).  The
same should happen

I believe that this is representative of real-world use cases.  If you
want to be rebooting your whole network often, they perhaps Babel is not
the right tool for the job.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Fastest convergence possible

[Juliusz Chroboczek]

> However, using a more convoluted 7-node setup I can hardly get under 40
> seconds. 

How are you measuring?  Are you rebooting your routers, or merely toggling
links up/down?

If the latter, than there is a problem.  If the former, then you should
either make sure that the state file is preserved across reboots, or run
with "random-id true".

Explanation: a Babel router's seqno must be preserved across reboots in
order to avoid spuriously triggering the loop-avoidance algorithm.  This
is what the state file is used for.  If for some reason you cannot
preserve the seqno, the "random-id" option can be used to create a new set
of loop-avoidance state at each boot.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Route-dete :wq

[Juliusz Chroboczek]

>>> My thinking on this is that you only need the host routes when a client
>>> actually roams.

>> This is only going to work if you either use no hold time, or implement
>> the optional algorithm in Section 3.1 of rfc6126bis.

> I'm assuming you mean the ACKed retraction algorithm in Section 3.5.5?

Yes, sorry.  Colloquially known as Chouasne's algorithm.

> Well, that is quite useful in any case.

It's very useful, but it creates extra state, extra timers, and might
timeout over wireless (EIGRP style).  So I'm not really sure how I feel
about it.

(Take this litterally -- I don't know how I feel about it.)

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] Babel meeting at IETF 101 -- remote participation

[Juliusz Chroboczek]

Dear all,

According to the current version of the IETF 101 agenda, the Babel meeting
ought to take place on

  Thursday 22 March 2018 at 18:10 London (winter) time
  Park Suite
  https://tools.ietf.org/agenda/101/

Remote participation is possible, and warmly welcomed.  Please see

  https://ietf.org/how/meetings/101/remote/

You need to register in advance, but remote registration is free.  You
don't need to enable your webcam (which is nice if you're in your pajamas
at that time), in which case your questions and comments will be read out
by a friendly Jabber scribe.

See you all, or at least your avatars, on Thursday 22 March.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] babeld interface

[Juliusz Chroboczek]

> https://github.com/christf/libbabelhelper

When you feel you're ready, please provide me with a one-line description,
and I'll add a link to the Babel page.

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] Babel over DTLS

[Juliusz Chroboczek]

17:34:25.800782 IP6 fe80::a6b6:7003:d50:6868.6696 > ff02::1:6.6696: babel 2 (8) 
hello
17:34:25.801038 IP6 fe80::a6b6:7003:d50:6868.6696 > 
fe80::d17a:7827:dae0:58f1.6696: babel invalid header
17:34:25.801075 IP6 fe80::a6b6:7003:d50:6868.6696 > ff02::1:6.6696: babel 2 
(24) hello ihu
17:34:25.803681 IP6 fe80::d17a:7827:dae0:58f1.6696 > ff02::1:6.6696: babel 2 
(24) hello ihu
17:34:25.803944 IP6 fe80::a6b6:7003:d50:6868.6696 > ff02::1:6.6696: babel 2 
(24) hello ihu
17:34:25.804240 IP6 fe80::d17a:7827:dae0:58f1.6696 > 
fe80::a6b6:7003:d50:6868.6696: babel invalid header
17:34:25.804298 IP6 fe80::d17a:7827:dae0:58f1.6696 > ff02::1:6.6696: babel 2 
(40) hello ihu ihu
17:34:25.804518 IP6 fe80::a6b6:7003:d50:6868.6696 > 
fe80::d17a:7827:dae0:58f1.6696: babel invalid header

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] babeld interface

[Juliusz Chroboczek]

> The main benefit of a well-known format is that the requirement for a
> client goes from easy parsing code to *no* parsing code.

Right.  So either we add a dependency on JSON to babeld, or we add
a trivial parser to every program that consumes babeld's input.

> In this example, parsing the custom format in Python would be something like:

No, parsing input using string.split is always incorrect.  You really want
to write a proper lexer.

The lexer I posted above is 70 lines of C, including full error checking.
In Python, it's probably 15 to 20 lines.  Is it really worth switching to
a bloated and unreadable format in order to avoid 20 lines of code in each
client?

The problem that JSON aims to solve is not very complicated, and JSON doesn't
solve it particularly well.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] babeld interface

[Juliusz Chroboczek]

> I agree that the current format is very easy to parse for a human, which
> is a benefit. I am struggling to have a machine parse this though.

You need a lexer.  Here's a simple lexer for you:

  https://www.irif.fr/~jch/software/babel/babel-lexer.c

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] Branch unicast

[Juliusz Chroboczek]

Hi,

I've pushed the code to run Babel over unicast.  It's in branch "unicast".

In order to use it, you need to say in your config file:

default unicast true

It's a per-interface parameter.

The code is pretty nasty, and not up-to-date with master, so I'll probably
be rebasing it some more.  Since Antonin is basing his DTLS code on this,
we'd be grateful for proof-reading and testing.

Note that I didn't need unicast Hellos.  I'm still not sure they should stay.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] babeld interface

[Juliusz Chroboczek]

> Nils and I wrote such a daemon, called mmfd. It is able to forward
> multicast packets in the whole network. To learn about the topology and
> the relevant neighbours, it queries babeld: mmfd is listening via
> "monitor" on the babeld socket.

Good.

> What do you think of providing the same data over json to make it better
> parsable?

The format of the monitoring interface is well defined : it's a series of
lines of the form

  keyword id key value key value ...

where each key/value is either space separated, or a string within double
quotes.

This format is extensible (we can add new keywords and new keys at any
time), and it's also easy to parse by a human (Antonin and I have just
spent much of today telnetting by hand into Babel's monitoring interface).
So I'm not convinced that switching to JSON would have any benefits.

Please let me know if you disagree, I'm not fundamentally opposed to
adding a new command "monitor-json" if you think it's desirable, but I'd
rather avoid the added complexity.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] The b8fb6d896a234eaa06 commit in master

[Juliusz Chroboczek]

> I didn't mean any present incorrect behaviour, but rather a weakness which may
> (or may not) reappear at some point later and cause painful bugs

I'm not worried, that's the kind of issue that valgrind is good at
detecting (and I regularly run babeld through valgrind).  There's plenty
of other places in babeld where I use this style.

Thanks for the note, and please continue reviewing master, I'm doing my
best to release it Real Soon Now.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] The b8fb6d896a234eaa06 commit in master

[Juliusz Chroboczek]

> I noticed that there's this new commit (b8fb6d896a234eaa06) which removes
> explicit initialization from check_xroutes() in xroute.c.

Fixed, thanks.

(I don't know what I was thinking when I accepted this patch.  I need a rest.)

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] SOLVED - routes appearing later than hoped-for

[Juliusz Chroboczek]

> The implementation does not have all the battle-tested optimisations of
> babeld at the protocol level.

On the other hand, babeld suffers from having too many features (it serves
among others as a platform for student projects), which implies having
bugs.  Like the bug that Gwendoline and Christof have identified.

I'm not particularly proud of myself.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Route-dete :wq

[Juliusz Chroboczek]

> One thing that fell out of that was mainline babeld had a very
> suboptimal routine for merging routes (also it's use of memcmp was
> inefficient) - and juliusz put out a call for a qsorted implementation
> a while back.

Just to be clear -- the quadratic behaviour is for routes redistributed
from another routing protocol.  Routes learned from other protocols use
a O(log n) data structure.

But you're right to remind me of the issue, I really ought to take care of
it after I get 1.8.1 out the door.

> I have high hopes for the unicast stuff to lighten the routing load by
> potentially orders of magnitude.

We'll see.

> The biggest problem I've run into, is that meshy links, are, meshy -
> and I've lost track of the number of times where
> I had a well defined /16 network in the lab suddenly leak all the
> meshy /32 bits over the worst possible link - because I plugged
> something in that was adhoc (and poorly) connected to the outside
> network that I shouldn't have.

Yes, filtering is error-prone.  I have some ideas about making it less so.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] SOLVED - routes appearing later than hoped-for

[Juliusz Chroboczek]

> I like to share what I do. Will you be in Berlin for the BattleMesh this
> year?

I haven't decided yet, I've got a lot of work in May and I'm already going
to IETF this spring.

> I am hesitant to implement this because that would require l3roamd to
> identify all the AP on the path and then sending them routing updates.
> This is way more complicated than a solution in babel.

Please don't.  That's Babel's job, and if it doesn't do its job, then it's
a bug (either in the protocol or the implementation) and must be fixed.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] Implementations of Babel [was: routes appearing later than hoped-for]

[Juliusz Chroboczek]

> I wasn't aware of Toke's implementation of babel so far. Why are there
> two?

I happen to believe that open (published) file formats and open protocols
are way more important than free software.  If the protocol is published,
then it is easy enough to redo the implementation; if the protocol is
closed, than even if you've got the source code, reverse-engineering the
protocol might be difficult or even impossible.

Now how do you verify that a protocol is written down in enough detail
that it can be reimplemented independently?  By asking your good friends
to reimplement it.  Since I've got plenty of good friends ;-), we ended up
with four independent implementations of Babel:

  - I did the original implementation (with help from Grégoire Henry and
Julien Cristau),
  - Markus Stenberg did a toy implementation in Python;
  - Toke Høyland-Jørgensen did a high-quality implementation within BIRD;
  - David Schinazi did a top-secret, proprietary implementation.

A nice side-effect of having multiple implementations is that it keeps me
honest: with multiple implementations, I cannot evolve the protocol
without consulting the community.  This means that even if I become
completely crazy tomorrow, the protocol has a good chance to remain
relatively sane.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Route-dete :wq

[Juliusz Chroboczek]

> I think babel is meant to do triggered updates however using tcpdump I was
> not able to see them when the route was inserted.

That's a fair assessment.  Triggered updates are broken in 1.8.0, they
should work in current master.  (My fault for introducing the bug, and
full credit to Gwendoline Chouasne for showing me the issue.)

Folks -- I'm badly overworked right now, if you can help with testing
current master, I'll be grateful.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Route-dete:wq

[Juliusz Chroboczek]

Christof, I'm very much interested in your experiments, which are likely
to improve the quality of the Babel implementations.

> We have update-interval set to 5 minutes to reduce the load on the network
> because we are hoping to run this topology on 500+ APs with 1000+ Clients.

The protocol is very flexible, but the reference implementation is not
designed to work with such large update intervals.  The amount of data in
an update is pretty small, so I would recommend reducing the update
interval -- it should be fine with thousands of routes in your network.

The right way to reduce the amount of routing traffic in Babel is not to
increase the update interval (which can at best yield a linear reduction),
but to use aggregation and filtering (which can yield an exponential
decrease in a well designed network).  Dave Taht has been successful with
this approach, perhaps he'll want to chime in.

Note that babeld currently sends updates as a single burst when the upate
interval expires (the same is true of Toke's implementation of Babel, as
far as I'm aware).  For very large networks, it would be good to split
updates into one-packet pieces that are sent throughout the update
interval.  I'd be glad to accept a patch that does that.

> * making babel trigger updates on newly appeared routes

I've gone through different approaches for scheduling updtes, and the
current master is more aggressive with scheduling updates.  I'd need to
check to make sure, but I believe it already does what you suggest.  If
you have time, could you please check if current master improves things;
if it doesn't, we need to work together to improve the implementation (no
protocol changes will be needed).

You could also try Toke's implementation, which is very well written.

> * communicating the appearance of a route across the network outside
> babel and inserting that at the gateway

I'm not sure what you mean.

> What do you think about those approaches?

Please try current master.  If not, we'll need to think together about
redesigning our approach to sending triggered updates.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] removal of old/stale routes from babel

[Juliusz Chroboczek]

> I am using babel 1.8 in an experimental Freifunk network

Cool.

> It seems that routes are accumulating in this network. At the moment there
> are well over 600 routes being distributed by babeld (echo dump |nc ::1
> babelport reveals 617 lines).

> I am probably missing something essential here.

You're probably just seeing fallback routes.  (We'd need to see your dump
to be sure.)

Babel keeps a redundant routing table -- it keeps routes to every
destination through every single neighbour.  This way, it can switch to
a different route immediately when it detects that its current next-hop is
down.

If you have 10 neighbours and there are 60 routes in the network, you'll
see 600 routes in your routing table.  Don't worry, though -- a fallback
route is just a 60-byte data structure, so 600 routes take less than 40kB
of memory.  (Fallback routes are not visible to the kernel, and are not
announced over the network.)

You can distinguish between redundant routes and the routes actually used
by the "installed" flag -- a route that is marked as "installed" is
currently used for traffic, a route that is marked as "feasible" is
a fallback route that can be used straight away if necessary, a route that
is not marked is an "unfeasible" route, one that cannot be used without
doing a quick packet exchange to make sure that it is loop-free.

My advice would be:

  - don't panic, in large, friendly letters;
  - only start worrying if babeld starts having a large RSS or uses more
than a fraction of CPU;
  - use BabelWeb in order to better understand better what's going on in
your network:

https://github.com/Vivena/babelweb2

Please don't hesitate to send me a route dump (through the list or, if
you're concerned about your users' privacy, by private mail), I'd be
curious to see what's going on.

Thanks for the input,

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Propagation of unknown sub-TLV?

[Juliusz Chroboczek]

Ok, I see.

> The algorithm let every node in a network compute its own value of "Load
> Centrality" and afterwards let nodes disseminate computed indexes so
> that each node, at convergence, is aware of the centrality index of all
> nodes in the network.

[...]

> For the moment forget that actually Updates advertise distances
> associated to prefixes, not to router-ids...we just wanted to work on
> a network graph-layer.

That's the whole point.  Babel is a distance vector protocol, it
advertises routes to given prefixes.  Now, of corse, prefixes are
originated by nodes (that's what the router-id identifies), but Babel does
not flood information about nodes:

  - if a node originates no route, then it doesn't appear on the wire at
all (Hello and IHUs carry interface identifiers, not node identifiers);
  - if a given prefix is advertised by multiple routers, then parts of the
network will only see one of the routes to that prefix;
  - finally, Babel doesn't use a reliable transport -- under heavy packet
loss, part of the information may be dropped (which is okay for its
intended purpose -- if there's such heavy packet loss, then there's no
point advertising routing information, since the routes are unusable
anyway).

In other words, Babel, as it currently stands, does not have provisions
for advertising node-specific information globally.

> Do you think the "transitive attributes" feature could be of general interest?

As a general rule, we try to avoid adding to Babel features that are not
useful for routing.  You could do one of the following:

  - design your own reliable flooding protocol; that's not difficult, I've
given it as a project to fourth year students and almost everyone
succeeded;
  - piggyback on a protocol that does reliable flooding, such as IS-IS or
OSPF;
  - piggyback on a protocol that does unreliable flooding, such as OLSR or
HNCP;
  - add a subprotocol for flooding of per-node information to Babel, but
to be entirely frank with you, I doubt it will get into mainline
babeld.

Please let us know what you decide -- I'll be glad to give a hand if
you're not sure what to do.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Propagation of unknown sub-TLV?

[Juliusz Chroboczek]

> I would like that Babel-nodes running an implementation of the original
> protocol (call them standard-nodes) would be able to "forward
> information" contained in sub-TLVs coming from "extended-nodes".

[...]

> Is it possible to accomplish this kind of “silent-propagation”?

No.  In Babel, an unknown sub-TLV :

  - is silently dropped if it is non-mandatory;
  - causes the whole enclosing TLV to be dropped if it is mandatory.

What you want is BGP's "transitive attributes".  There's no such feature
in Babel.

> For instance, I am thinking to this in order to deploy an extension
> without the need to reboot the whole network.

Perhaps you can describe your extension, so we can think about it together?

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Heads up: merged rfc6126bis into master

[Juliusz Chroboczek]

> While not exactly a flag day from a protocol perspective, the commit
> removing keep-unfeasible will break existing startup scripts and conf
> files that have it enabled.

> https://github.com/jech/babeld/commit/0111f5c1d69ce643a6a76a811eb8f89fb4deb936

Right.  Need to add it to the changelog.

(Keep-unfeasible is now the default, and is the behaviour recommended by
6126bis.  The previous default behaviour, which discarded unfeasible
routes, turned out to be a bad idea, since it meant we might not have
a route along which to send a request when we strarve.  The slight
additional memory usage should not be an issue.)

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] BABELD importing routes from linux kernel-table

[Juliusz Chroboczek]

> But I have a set of additional routes (created by olsrd) on
> - host_a (debian) in the main kernel routing table
> - host_b (openwrt) in a dedicated routing table

> But none of the gets considered to be announced.

You need to explicitly ask babeld to announce these routes.  You need to
add something like the following to your /etc/babeld.conf:

redistribute proto 3 allow

(I believe olsrd uses proto 3 to tag its routes, but I could be wrong.
Please check with "ip route show" and compare with /etc/iproute2/rt_protos).

If you don't want to announce the local host routes, you must additionally
add:

redistribute local deny

The redistribution and filtering language is fairly fine-grained, you
might want to check the babeld manual page if you have specific
redistribution requirements.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] babeld inside docker

[Juliusz Chroboczek]

> Hi, myself and Justin Kilpatrick have done a lot of this kind of stuff, and
> Docker is kind of a distraction IMO.

My colleagues are divided on that subject.  Matthieu is rather fond of
Docker, while Gwendoline prefers nemu.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] babeld inside docker

[Juliusz Chroboczek]

> I am trying to run babeld inside docker here:

> https://github.com/zoobab/babeld-in-docker

> I can't get 2 containers to see each other, and I can't figure out why
> (multicast or any ipv6 option might not be enabled by default).

> If someone can help...

Is the filesystem shared between the containers?  If it is, careful with
not sharing state files (check the -S option in the manual page).

What's the tunnelling technology?  Does it carry IPv6?  Is there
a link-local address on the interfaces?

What does tcpdump say?

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] About an authentication extension

[Juliusz Chroboczek]

> I see, however the project has already been accepted so i will have to
> do it anyway :(

Good.

Perhaps you can tell us more about the project, so we can work together at
tweaking its parameters to make sure it is useful to the wider Babel
community?  Preferably on the list, since there's a number of competent
people here, but if for some reason you prefer private mail to Toke and
myself, that's okay too.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] Babel@ietf meeting on Thursday: remote participation

[Juliusz Chroboczek]

Dear all,

This is to remind you that the Babel meeting will be tomorrow (Thursday):

  18:10 SGT (Singapore)
  11:10 CET (Paris, Warsaw)
  10:10 UTC
  05:10 EST (New York, NY)
  02:10 PST (Vacaville, CA)

If you have a reasonably recent web browser, remote participation is easy:

1. register here (you can do that in advance):

https://www.ietf.org/meeting/remote-registration.html

2. join us here (at the time of the meeting):

https://brasbasah.conf.meetecho.com/q-meetecho/login.jsp?ietf=babel

You don't need a webcam or a microphone, you can participate in the
discussion in writing and a friendly scribe will read out your
contribution.  If you prefer to lurk, you're very much welcome.

The agenda is here, and a copy of the slides will be uploaded as soon as
we're ready (grep for Babel):

https://datatracker.ietf.org/meeting/agenda/

Highlights:

  - David Schinazi will speak about the recent evolution of the protocol;
  - Juliusz Chroboczek will open the security discussion;
  - Zheng (Sandy) Zhang will speak about BIER over IPv6.

BIER is a technology for multicast forwarding that doesn't require
per-session state in every router, and therefore has a chance of getting
deployed.  Sandy and her team have been working on using Babel as the BIER
control protocol.  The introduction to BIER is rather readable:

  https://tools.ietf.org/html/draft-ietf-bier-architecture

Hope to see you tomorrow,

-- Juliusz Chroboczek

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Some notes on seqno requests in Babel

[Juliusz Chroboczek]

> The other values in the appendix are from babeld, aren't they?

Uh-huh.

I'll think it over.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] Fwd: Some notes on seqno requests in Babel

[Juliusz Chroboczek]

Forwarded with permission of the author.
--- Begin Message ---
Hi Juliusz and Toke

I am fixing some issues in Babel code in BIRD related to seqno requests
and i found that parts of the Babel RFC less than clear.

1) 3.2.6.  The Table of Pending Requests

   The table of pending requests contains a list of seqno requests that
   the local node has sent (either because they have been originated
   locally, or because they were forwarded) and to which no reply has
   been received yet.  This table is indexed by prefixes, and every
   entry in this table contains the following data:

The paragraph says that the table is indexed by prefixes. I would assume
it means that prefix is a unique key for the table, so no two entries
have the same prefix. That would work for forwarded requests, but IMHO
there may be multiple pending locally originated requests for the same
prefix with different router-id resulting from actions by section
3.8.2.2. Dealing with Unfeasible Updates.

I guess it could be handled by keeping only the request related to the
route with the best metric, or should we keep multiple pending
requests with different router-ids?

BIRD currently uses (prefix, router-id, seqno) as a key, where different
seqno values are clearly not necessary.


2) 3.8.1.2.  Seqno Requests

   If the requested router-id is not its own, the received request's hop
   count is 2 or more, and the node has a route (not necessarily a
   feasible one) for the requested prefix that does not use the
   requestor as a next hop, the node SHOULD forward the request.  It
   does so by decreasing the hop count and sending the request in a
   unicast packet destined to a neighbour that advertises the given
   prefix (not necessarily the selected neighbour) and that is distinct
   from the neighbour from which the request was received.

I am not sure why the paragraph emphasises 'node has a route (not
necessarily a feasible one) for the requested prefix that does not use
the requestor as a next hop' and what means '(not necessarily the
selected neighbour)', when in earlier paragraphs it is established that
seqno forwarding is only done if there is a selected route with the same
router-id.

I guess it is because the selected route may be one with the requestor as
a next hop and and in such case a different route (with the same router-id)
has to be used?


3) In appendix B, there are no hints about resending and expiration of
requests - suggested timeout values and number of resend attempts.
Are there any suggested values?

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."


signature.asc
Description: PGP signature
--- End Message ---
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Adding a monetary factor to routing cost

[Juliusz Chroboczek]

> I've got a working commit that adds price as an unsigned integer in
> between the metric and prefix fields in route updates.

You're modifying the base protocol rather than doing an extension, so
please change the header so that unmodified Babel routers don't try to
associate with your routers.  (Just change the "Magic" value in the packet
header to some other arbitrary value.)

> I think the best way to really handle this is just to add a price TLV,

Or a sub-TLV of the Update TLV.  No need for the mandatory bit, I believe,
but I'm not sure.

> which is somewhat more complicated to implement but more clean from a
> network perspective as price may not change as often as routes update
> for other metric reasons.

Another possible optimisation is to put the sub-TLV in the Router-ID TLV,
which will allow you to carry a single price for multiple routes
advertised by the same router.

> The easiest way I found to do it was to use a wireguard tunnel as
> a neighbor and then have an external program monitor the rtt,

Babeld can monitor RTT out of the box.  Please check the manual page, and also

  https://arxiv.org/abs/1403.3488

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Babel Admin Distance

[Juliusz Chroboczek]

Added babel-users to CC.

> During discussion about this the other night, I guessed at an admin
> distance of 100 for Babel.  In conversation this morning with Don
> Slice he indicated that a number of 100 might be a bit low as that do
> we really trust Babel more than OSPF?  Do people have opinions on what
> the Admin Distance should be set too?

Here are the real-world cases I know.

Our Babel network here in Paris uses FRR on its edge routers,
redistributing a default route from RIPng into Babel, and announcing
a static route over RIPng to the rest of the universe.  If there are two
edge routers, we want the RIPng route to be used instead of the Babel
route announced by the other edge router, so Babel must have a higher AD
than RIPng.  (My employer happens to use RIPng for IPv6 routing, but
the same argument would apply to OSPF or IS-IS.)

The Italian confederation of mesh networks uses a mixture of OLSR,
BATMAN-adv and Babel in its individual meshes, and uses Babel for routing
between the individual meshes (mainly due to the minuscule amount of
traffic it generates as compared to the traditional mesh protocols).  I'm
not entirely clear how redistribution is done in the confederation, but
I believe that they'd prefer Babel to have a lower AD than OLSR.

The Slovenian mesh network (wlan-si) uses both Babel and OLSR.  If a given
prefix is carried by both Babel and OLSR, I believe that they prefer the
Babel route.  This, again, implies that Babel's AD should be smaller than
that of OLSR.

The Nexedi overlay network uses Babel for routing between LANs, mainly due
to its ability to choose the best among a set of parallel tunnels.  They
don't do any routing within the LANs, so any AD will do for them.

The above examples would seem to imply that Babel's AD should be between
that of traditional IGPs and that of traditional mesh protocols.  However,
I don't see any reason why a deployment wouldn't use Babel to distribute
externals between OSPF and IS-IS islands (e.g. in cases where Babel is
being used to pick the best among parallel tunnels, as in Nexedi's case),
so having Babel's AD lower than that of traditional IGPs would appear to
make sense in some cases.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] [babel] routing tables of death

[Juliusz Chroboczek]

>> I confess curiosity, now that we have quagga, bird, and mainline babeld
>> versions, and nifty new stuff like unicast hellos, as to how well they
>> interoperate at this point, as well as perform, under a stress test like:

> And FRR...

Babeld and FRR are known to interoperate, but that's little surprise,
since they're based on the same code.

Quagga (the better-named ancestor of FRR) does not have a Babel
implementation.

Perhaps Toke and David can tell us more about the tests they've done with
their respective implementations.

(It would definitely be a cool thing to organise an interop event, perhaps
here in Paris.  Not before 2018, though, the way my schedule is going.)

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] Babel in FRR

[Juliusz Chroboczek]

Hi folks,

As some of you may be aware, FRR master branch speaks Babel.

  https://github.com/FRRouting/frr

The Babel support is based on Matthieu's old Quagga code.

After some bug fixing by Donald Sharp (thanks!), it's reached the level of
maturity where it can run as an edge router for both IPv4 and IPv6.  I've
set up a node that speaks RIPng to my upstream router, and Babel to the
Babel network.

If you want to try it out -- beware that the docs are incorrect: you need
to say "redistribute ipv6 ripng" or "redistribute ipv6 static" where the
docs say "redistribute ripng" or "redistribute static".

-- Juliusz



___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] BabelWeb 2

[Juliusz Chroboczek]

> Could it run on openwrt and mips?

No, GC built binaries for MIPS32 currently require an FPU.  I've put
a small ARM board behind my router for that very reason.

The Go team are aware of the issue, and I'm optimistic that this will be
fixed ina future version.  You'll still have to live with the humonguous
binaries that GC produces (babelweb2 is 4 MB of text in a 6.5 MB file).

As to gccgo, I'm not interested, since I'm a big fan of the Go scheduler,
which gccgo doesn't implement.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] BabelWeb 2

[Juliusz Chroboczek]

> Cool, but how do I build this thing?

> % go get -v github.com/Vivena/babelweb2
> github.com/Vivena/babelweb2 (download)
> package babelweb2/parser: unrecognized import path "babelweb2/parser"

Thanks for the report, I've forwarded it to the authors.

In the meantime, you can do:

  cd ~/go/src
  go get github.com/gorilla/websocket
  git clone https://github.com/Vivena/babelweb2
  cd babelweb2
  go build

Two caveats with this early version:

  * the "static/" directory must be in the current directory when you run
the babelweb2 binary;
  * if you don't run the server on localhost only, you need to change the
URL on line 40 of static/js/initialise.js.

-- Juliusz



___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] BabelWeb 2

[Juliusz Chroboczek]

> Nice. But the demo needs more routers :P

Too tired right now, sorry.  I need to set up FRR or BIRD to speak RIPng
to our Cisco, so the Babel network gets a default IPv6 route, and to set
up a few wireless routers in random places.

> Is it documented somewhere what information the interface needs from the
> routing daemon in case someone wanted to support it from another routing
> daemon (purely hypothetically speaking, of course ;))?

It needs to know, for each route:

  - the announced metric;
  - the computed metric;
  - the next hop;
  - the router-id.

It matches next-hops with router-ids by looking for routes with announced
metric being zero, so if your network doesn't have enough such routes, it
will not work very well.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] Top secret Babel meeting on Wednesday -- unicast hellos

[Juliusz Chroboczek]

Dear all,

I've been tasked with organising a meeting about unicast Hellos in Babel.
I've consulted the people I could reach, and Wednesday morning appears to
suit at least a few of them.

So let's meet on

  Wednesday 19 July at 10am

I'll see tomorrow morning if I can get a room at the Hilton.  If I cannot,
I'll bribe some friendly cafe owner to give us a table (I'm sure we'll
drink enough tea, coffee and Czech Coke to make it worth his while).

I'll send an e-mail to the list to confirm the exact appointment.  See you
all on Wednesday,

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] IETF Babel meeting in Prague on 17 July -- remote participation possible

[Juliusz Chroboczek]

Dear all,

The Babel working group meeting at IETF 99 will be on

  17th July 2017 at 17:40 CEST in room Athens/Barcelona

If you're attending IETF 99, please come.  If you're not attending, please
do try to participate over this new-fangled Interenet thing:

  https://www.ietf.org/meeting/remote-participation.html

I've had good experience with Meetecho in the past.

Should you be in Prague, I'll be there all week, and I'm always glad to
meet Babel users.  And while I would never, ever encourage you to attend
the meeting in person without paying the outrageous IETF admittance fee,
past experience shows that there are usually no armed guards at the entrance.

See you hopefully in Prague,

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Should I use wifi mesh routing in crisis situations?

[Juliusz Chroboczek]

>>   1. ad-hoc mode doesn't work as well as infrastructure mode;

> Has anyone tries using 802.11s configured interface?

Interesting idea.  I'd be surprised if it worked much better than plain
ad-hoc mode, but I'd love to be proved wrong.

>> If you're using diversity routing (Babel-Z), be
>> aware that current versions of babeld are unable to automatically
>> determine the channel number of interfaces in AP mode -- you'll need to
>> set them manually.

> We are using wlan-slovenia firmware, and AFAIK this is regular babel.
> I'll read up on babel-z.

It's included in the babeld binary.  Just add "diversity true" to the
config file.

The protocol is described here:

  https://tools.ietf.org/html/draft-chroboczek-babel-diversity-routing

> I'll try this and let you know... but how would interfaces then be
> configured? One side all AP and other side all STA interfaces?

I agree, it's a pain to configure -- I too wish that ad-hoc mode worked
better.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Should I use wifi mesh routing in crisis situations?

[Juliusz Chroboczek]

Hi Valent,

> my name is Valent and I'm founder of www.otvorenamreza.org which is a
> partner project with Wlan Slovenia (we are neighbours) and also
> www.meshpoint.me

We know.  You're famous :-)

> We currently have mostly single radio nodes (tplink wr841nd and
> ubiquiti nanostation Loco m2) in our network and by default all of our
> nodes also run mesh on same radio but via adhoc interface.

> In my short experimentation this showed to work quite poorly, even
> with two nodes separated by only 10 meters on top of two building this
> mostly failed to work and we had lots of connectivity issues. Once I
> switched these two nodes to ap and sta modes link was rock solid.

Yes, that kind of setup tends to suck.  There are two issues with your setup:

  1. ad-hoc mode doesn't work as well as infrastructure mode;
  2. using the same frequency for transit and client access reduces througput.

For (1), the best solution is to set up a bunch of point-to-multipoint
links using AP/STA mode.  If you're using diversity routing (Babel-Z), be
aware that current versions of babeld are unable to automatically
determine the channel number of interfaces in AP mode -- you'll need to
set them manually.

For (2), the best solution is to use multiple radio frequencies.  If you
have two frequencies, use one for client access and one for transit.  If
you have multiple radio frequencies, set all but one of them for transit,
and let Babel-Z choose the frequencies.

If multi-radio routers are too expensive for you, Babel-Z is able to work
with the "JBOL" topology: a bunch of single-radio routers, all connected
to the same Ethernet switch (possibly internal to one of the routers).  If
the channel numbers are set up correctly, Babel-Z should be able to
distribute traffic across multiple frequencies in that configuration.

Please let us know about your results,

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Unscheduled Unicast Hellos: some background on 802.11 link quality estimation

[Juliusz Chroboczek]

> I'm wondering... what if, in the hypothetical routing protocol "Babble",
> one got rid of multicast hellos and ETX entirely, and routed using RTT
> measured by unicast hellos.

Interesting idea.

I think that's a perfectly legitimate implementation of Babel with Unicast
Hellos: we're leaving the cost computation algorithm unspecified, ETX is
just an implementation suggestion in Appendix A.

> Wouldn't this take delays from ARQ'ed packet oss into account have
> results somehow similar to ETX?

802.11 has a default ARQ timeout of 1µs, which is likely to be drowned by
congestion.  I guess the only way to find out is to try it out.  You'll
need to change the packet format of the ETX extension, which only has 1µs
granularity.

-- Juliusz



___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Unscheduled Unicast Hellos: some background on 802.11 link quality estimation

[Juliusz Chroboczek]

>> 2. 802.11 uses adaptative rate control on unicast frames, but not on
>> multicast frames.

> This is not entirely true, since hostapd is able to send multicast as
> unicast-frames.

And this will cause Babel's link-quality estimation to yield incorrect values.

Dynamically computed metrics are an open area of research, and one that is
sadly neglected by the scientific community.  I believe that it is
important, but it is very difficult to publish in that area (FWIW, our
paper about the RTT metric was rejected twice).

ETX is an elegant hack that uses the fact that 802.11 multicast isn't
subject to ARQ.  As you justly note, Ruben, this assumption can fail in
edge cases, and there's nothing that can be done about it.  The obvious
solution would be to have explicit cross-layer signalling, as in the case
of Lamparter's variant of IS-IS.  Doing that right is not easy, and might
(or might not) require changes to the link-layer.

I'm personally interested in that area of research, and I'll probably have
a fair amount of funding in the near future.  However, since the area is
not fashionable, I cannot promise that we'll be able to publish.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] [babel] Unscheduled Unicast Hellos: some background on 802.11 link quality estimation

[Juliusz Chroboczek]

> Can you provide text?

Yes, I will do.  Please focus on specifying the on-the-wire bits, I'll
take care of the appendix.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] [babel] draft-boutier-babel-source-specific-02

[Juliusz Chroboczek]

> Does this mean whatever we decide for wildcard requests applies to
> wildcard updates as well?

Yes, er, no, er, I have no idea.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] WBMv10: CDF graphs of ping test

[Juliusz Chroboczek]

I've put some CDF graphs of the results here:

  https://www.irif.fr/~jch/software/babel/battlemeshv10.html

I've omitted the BATMAN5 data, since it was adding a lot of noise to the
graphs.

It looks like Babel did very well in the 8-17 test, and resonably well in
the others but with a fair number of very high RTT samples.  BMX7 is the
winner in all tests except 8-17 (where it is soundly beaten by Babel).

I don't see any obvious pattern in the data, and I'm at a loss to explain
the behaviour.

The scripts are at the bottom of the page, please feel free to reuse them
in the official document.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Basic settings to enable RTT metric.

[Juliusz Chroboczek]

> Hi, I was wondering what is the best way to enable the RTT metric with
> sensible defaults. It looks like max-rtt-penalty is the option that turns it
> on. What is a good value to set this at starting out? 

Yeah, the RTT metric is fiddly.  For very good reasons -- it's an
intrinsically unstable metric (it contains a feedback loop).  I suggest
you have a look at Section III.D of

  https://arxiv.org/pdf/1403.3488.pdf

The most important parameters is rtt-max.  It should be configured as
a sufficiently large value, but small enough that the latency of highly
congested bottleneck links is higher than rtt-max.  The default value of
120ms works well in the global-scale overlay networks we've experimented
with.

Rtt-min and max-rtt-penalty don't matter much -- if rtt-max is chosen
wisely, the algorithm will be reasonably stable whatever the other values.
Rtt-min should be a value slightly larger than the latency of completely
uncongested low-latency links; the default value of 10ms should be fine
for most applications.  max-rtt-penalty determines how much high-latency
links are penalised; any value between 128 and 384 should yield decent
results, I suggest starting with 197 (which happens to be a prime number).

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Fw: Diversity routing configuration help

[Juliusz Chroboczek]

For anyone interested, the Z3 algorithm is named in honour of Benjamin,
the author of the mail I'm replying to.

> Beware also that babel does not support all "recent" channel configurations:

> https://wiki.freifunk.net/ideas

That's not quite true.

> In the absence of explicit diversity routing information supplied by
> the protocol, the z3 algorithm assumes that a given route is
> interfering, even if the interface over which a route is learned is
> obviously not (usbnet), or probably not (ethernet).

That's obviously false.  Babeld-Z3 detects Ethernet interfaces, and
assumes they interfere with no other links.

> Diversity routing also does not take into account (presently) the
> number of ways channels can be combined in the various wifi standards.
> HT20 covers 4 channels, HT40, 8, HT80, up to 2 sets of 4 channels, and
> so on.

That's correct.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Fw: Diversity routing configuration help

[Juliusz Chroboczek]

> R1(AP mode) ---> R2( Station mode)

All of your routes are single-hop, so there's no diversity information
being propagated.  You'll need some longer routes in order to see anything..

> The channel information remains as 11 and 36 for station mode but ap
> mode it is 255. Whether it is expecting behavior ?

Yes, it's a known issue -- babeld doesn't know how to detect the channel
in AP mode (we need to switch to a newer API in order to do that).  In the
meantime, you can configure the channel number manually:

  interface wlan0 channel 42

(with the correct value for 42, of course).

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] [babel] draft-ietf-babel-rfc6126bis-02

[Juliusz Chroboczek]

> I have implemented support for subtlvs and the mandatory bit in
> Bird[1][2] and confirmed that it correctly discards source-specific
> updates from Matthieu's branch.

Thanks, Toke!

I should be a little more free starting this week-end, I'll try to get
mandatory bits in all remaining implementations.  The Nexedi fork of
babeld will probably be the most difficult, and require some face-to-face
meetings.  (But they're a fun bunch to work with, and they usually buy me
lunch, so that's okay.)

-- Juliusz


___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] [babel] source sub-tlv

[Juliusz Chroboczek]

Matthieu, could you please write up a new version of the I-D with your
encoding?  You might want to speak to Gwendoline, since she needs to write
up her TOS-specific encoding.

> If we keep this behaviour and mix tos-specific routes, we will have
> to send 4 wildcard requests to have all routes.  I see two reasonable
> options:

>   - only keep (legacy) wildcard requests, and reply with a full dump.

That's reasonable, although slightly confusing.  (Call that (1).)

>   - send one request with all sub-TLVs you know but without mandatory
> bit, and reply to all options you know about.

That's not -- it would require allocating a full new set of sub-TLVs.
Plus I find this confusing.  (Call that (2).)

There are two other possibilities:

  3. Send a non-specific wildcard request for non-specific routes,
 a source-specific wildcard request for source-specific routes, etc.

  4. Deprecate wildcard requests -- say that they MAY be replied to, but
 SHOULD NOT be sent by new implementations.

Now wildcard requests are fairly rare -- they are only used to speed up
convergence at boot time, as well as by debugging tools (although we have
no such debugging tools yet -- all debugging tools known to me connect to
the local socket of a node).  So sending four TLVs in a single unicast
packet instead of a single TLV is not prohibitive, and is much simpler
than the alternatives.

I support (3).  Last time I spoke to him, Toke supported (4).  I am
opposed to (2).  I can live with (1).

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Fw: Diversity routing configuration help

[Juliusz Chroboczek]

> Unable to find the channel information.

Send the SIGUSR1 signal to babeld (killall -USR1 babeld), then check the
log (using logread if a recent version of LEDE/OpenWRT, in /var/log/babeld.log
if using an older version).

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Diversity routing configuration help

[Juliusz Chroboczek]

> Can anyone help me regarding sample config's for diversity routing babel
> configuration.

Just say

  diversity true

in /etc/babeld.conf.

You can check that it's working by running babeld with the "-d1" flag, and
checking that the routes carry reasonable channel information.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Running Babel exclusively on Ipv4

[Juliusz Chroboczek]

While the protocol is defined to work over either IPv6 or IPv4, all
implementations known to me use IPv6 for control traffic.  If you need to
run Babel over a network that cannot carry even link-local IPv6, you'll
need to modify the implementation.

The alternative is to set up an overlay network.  This has some advantages
in any case, especially if you're running over infrastructure that you
don't control.  You may want to look at what the Nexedi people are doing:

  https://www.erp5.com/NXD-re6st.Two.Page

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] Fwd: [homenet] Mailing list for Homenet Babel Security design team

[Juliusz Chroboczek]

--- Begin Message ---
There is now a mailing list for the design team specifying the
integration of HNCP and Babel security.

The list address is homenet-babel-...@ietf.org

We have added those people that had initial discussions around this
during IETF 97.

Ray and Mark

___
homenet mailing list
home...@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

--- End Message ---
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] [babel] Mandatory bits in babeld

[Juliusz Chroboczek]

> I've just done a first draft of mandatory bits in babeld.  The code is in
> branch "mandatory" of the github repository.  It doesn't look *that* bad.

Matthieu and Gwendoline have fixed some bugs, so if you're tracking that
branch, please pull.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] Mandatory bits in babeld

[Juliusz Chroboczek]

Hi,

I've just done a first draft of mandatory bits in babeld.  The code is in
branch "mandatory" of the github repository.  It doesn't look *that* bad.

If nobody objects too loudly, I'm going to write the protocol up in the
rfc6126bis draft, then merge the mandatory branch into master.  Please
scream loudly now, or forever hold your peace.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Question about the status of RFC7298

[Juliusz Chroboczek]

> I'm working on securing routing metrics from forgery rather than
> actual encryption/security for the data in transit. I doubt what I
> come up with will end up meeting anyone else's requirements nor be
> upstreamable due to just how much I'll probably end up touching on.

You might be surprised.

> So thanks for the warning but I'm off to make a fork anyways so I'm
> not concerned.

Please stay in touch nonetheless.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] Fwd: [babel] About mandatory bits

[Juliusz Chroboczek]

Folks,

If you have an opinion on the subject, please chime in on ba...@ietf.org.

--- Begin Message ---
Dear all,

As some of you have hinted (more or less rudely), there is an alternative
to the AE-based encoding of source-specific and TOS-sensitive routes that
I suggested: adding a mandatory bit to sub-TLVs.  The mandatory bit has
a number of advantages, and a number of cons when compared to the
multiplication of AEs.  Here are my thoughts on the subject -- I'm very
much interested in your opinions.

Encoding


The mandatory bit could be encoded as the top-order bit of the sub-TLV
type octet.  The sub-TLV format would then become:

 0   1   2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Type|Length |  Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

This reduces the sub-TLV type space, but that is not a problem since the
type space is extensible -- if we run out of sub-TLV numbers, 16-bit TLVs
can be encoded in a backwards compatible manner as follows:

 0   1   2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|  127|   Length + 2  |  Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-


Semantics
*

Mandatory and non-mandatory sub-TLVs are allocated separately -- mandatory
sub-TLV 2 does not necessarily have any relation with non-mandatory
sub-TLV 2.  An implementation MUST parse all the sub-TLVs of any TLV it
does not ignore, and if a TLV contains an unknown mandatory sub-TLV, then
the whole TLV MUST be silently ignored.

There's an implementation cost here: every implementation, even if it
doesn't do any extensions, MUST learn to parse all sub-TLVs, and to drop
TLVs that contain unknown mandatory sub-TLVs.


Compatibility
*

No existing extensions are broken by mandatory bits: since all currently
defined sub-TLVs have small type numbers, they appear as non-mandatory
sub-TLVs, which preserves their semantics.

On the other hand, mandatory sub-TLVs stretch the weak compatibility that
we decided on in London.  Legacy implementations will get confused by
mandatory TLVs, treating them as non-mandatory, and, by mis-interpreting
updates with mandatory TLVs, might create routing loops.  I am not sure
whether this is acceptable at that stage.


Encoding of exciging extensions
***

Mandatory bits allow a very simple encoding of both source-specific and
TOS-specific updates: a source-specific update is just a normal update
with a mandatory source-prefix sub-TLV, while a TOS-specific update just
carries a mandatory TOS sub-TLV.

The extensions combine easily -- just put both mandatory sub-TLVs.


Cost for implementations


All implementations -- even minimal ones such as sbabeld or pybabel --
MUST learn to parse sub-TLVs in order to detect mandatory ones.  This is
an implementation cost, but one that only applies to minimal
implementations, since full-fledged implementations most likely already
know how to parse sub-TLVs.

This implementation cost is not outrageous -- we're speaking of a dozen
lines of C code or so.


Other applications
**

The Italian mesh communities have requested the ability to tag routes with
opaque tags.  They want to be able to filter routes without configuring
each router with a list of prefixes, e.g. to have all Roman routers
originate routes with a "Roma" tag, and just configure non-Roman routers
to filter out the Roman routes.  Mandatory bits encode this easily.

Mandatory bits on Hello TLVs prevent associating with routers that don't
implement a given extension.  This allows an easy way to perform feature
negotiation, with no new mechanism.


Cultural compatibility
**

Mandatory bits are familiar from BGP and OSPF.  That puts people at ease.


Elegance


Elegance is in the eye of the beholder, but to my eyes mandatory sub-TLVs
are more elegant than the multiplication of AEs.


Conclusion
**

Unless I'm missing something, mandatory bits are a simple, elegant and
powerful mechanism that fits well in Babel.  However, they silently break
compatibility in a manner that might or might not be unacceptable to our
user base.

Opinions?

-- Juliusz

___
babel mailing list
ba...@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--- End Message ---
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] Unicast Hellos

[Juliusz Chroboczek]

Dear all,

[This message is crossposted between both mailing lists, followups to
babel@ietf, please.]

I think there are at least four people interested in making a unicast-only
version of Babel, and that requires adding support to the protocol for
sending Hellos over unicast.  We had a discussion on this subject with
David Schinazi on Friday, let's please continue on the list.

Background
==

Babel was designed so that the choice between sending a given TLV over
unicast or multicast is purely an implementation decision: all TLVs can be
sent over either, and have exactly the same meaning whether they are sent
over unicast or multicast.  There is however one limitation to that:
Hellos carry a per-interface sequence number, and unless they are sent to
all neighbours on a given interface, the seqnos will get out of synch.
More on that below.

At the time, it didn't seem important to be able to send unicast Hellos.
After all, Hellos are used for both neighbour discovery and neighbourship
maintenance, and discovery can only happen over multicast.  However, once
a neighbour has been discovered (either through multicast Hellos or
through means exterior to the protocol), then unicast Hellos can be used
to maintain the neighbour relationship.

People have found good reasons to use unicast for Hellos:

  1. Toke and Dave have a passionate hatred of multicast, and want to
 avoid it whenever possible;
  2. others want to protect Babel with DTLS or IPSec, and these protocols
 only work for unicast;
  3. Margaret is using Babel over a non-broadcast network, where multicast
 is not supported at all.

All of these are legitimate applications, and as I mentioned in Chicago,
it would be a terrible wasted opportunity if we didn't get unicast Hellos
into the spec in time for Prague.

The issue
=

Every Hello contains two pieces of information: the Interval, a 16-bit
number of centiseconds (ranging from 10ms to 11 minutes), and a 16-bit
Seqno, which is an integer modulo 2^16.  The Interval is a promise to send
another Hello within a given time; babeld uses it to derive a hold time
(3*Interval, if memory serves).  The Seqno is incremented with each Hello,
and allows for reliable accounting of packet loss.

A Babel speaker maintains a single Hello Seqno per interface, which is
incremented whenever a (multicast) Hello is sent.  If a Hello is sent over
multicast to a single neighbour, the expected Seqno will become
desynchronised between the various neighbours, which will cause spurious
detection of packet loss.

A Hello also carries a 16-bit Reserved field, which currently must be zero
on transmission, and is silently ignored on reception.  David suggests
that this field could be repurposed as a flags field.

Possible solutions
==

It is my opinion that it is allowable to add an incompatible extension as
long as it does not break existing networks and does not require a flag
day.  If a unicast-only speaker fails to establish an adjacency with
a legacy speaker, that's fine with me, as long as it does not break the
rest of the network.  Given that constraint, David and I see the following
ways to add unicast Hellos.

Allow unicast, no other protocol changes


Margaret suggests that we should allow unicast Hellos, but require that
the same number of Hellos be sent to all neighbours on a given interface.
In other words, whenever a Hello is sent, it is either sent over
multicast, or the same Hello is sent to all neighbours over unicast.

This is tempting, since it doesn't require any changes to the protocol,
just minor editorial changes.  While it meets Margaret's use case, it
might not be flexible enough for all the uses of unicast Hellos.  I also
dislike the fact that the receiver cannot distinguish unicast from
multicast without checking the destination address -- this would be the
only place in the protocol where the destination address is needed.

Make the Hello counter per-neighbour


No protocol changes, just require that the Hello counter be per-neighbour.
This means that an implementation must either send all Hellos over
multicast, so all per-neighbour counters are equal, or all Hellos over
unicast.  Once a Hello has been sent over unicast and the counters have
become unsynchronised, it is impossible to send a Hello over multicast.

This is not acceptable to me, since sending Hellos over multicast is the
only in-band way to perform neighbour discovery.

Two kinds of Hellos, distinguished using a flag
***

David suggests that we have two Seqno counters: a per-interface and
a per-neighbour counter.  The two kinds of counters run independently.
A flag in the Hello packet's Reserved field serves to distinguish the two.

This is simple, elegant, and require few protocol changes.  Unfortunately,
legacy implementations that don't parse the Reserved field will get

[Babel-users] Babel meeting at IETF-98, remote participation possible

[Juliusz Chroboczek]

Dear all,

This is just to remind you that there will be a Babel meeting at IETF-98
in Chicago this Tuesday at 13:00 CDT.  That's 19:00 Paris time, if I'm not
confused.

  https://datatracker.ietf.org/meeting/98/agenda.html

(The Homenet meeting is on Monday.)

You're all warmly encouraged to participate remotely (you don't need to
register in advance):

  https://www.ietf.org/meeting/98/remote-participation.html

I recommend meetecho, although it doesn't work in all browsers (it works
for me in either Mozilla or Chrome, I don't remember which, and Matthieu
got it to work on a Mac).

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] [PATCH 1/6] Improve Makefile

[Juliusz Chroboczek]

Not applied.

> - Add INCLUDES variable for headers

What for?  Why do I need to maintain an extra variable?

> - Add support for tags and TAGS

No objection, but I just use a private shell alias.

> - create "reallyclean" to get rid of tags, TAGS, gmon.out, cscope.out

Rejected.  There's no need to introduce multiple levels of cleanliness,
either the tree is clean or it isn't.

> - Add full and correct dependencies on internal headers

Rejected.  There's no way I'll be able to maintain that.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] [PATCH 4/6] Tests: Add subdir and test for structure packing

[Juliusz Chroboczek]

Rejected.

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] [PATCH 5/6] gitignore tags TAGS emacs and vi temp files and bad patch attempts

[Juliusz Chroboczek]

Applied.

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] [PATCHes] Misc cleanups to the babeld build system

[Juliusz Chroboczek]

> In part I broke up the makefile changes because I figured you wouldn't
> like the compile guards
> and whole program stuff, but I found that really helpful later on in the
> rabeld effort, while optimizing and trying to understand how things
> worked.

You're right, don't overdo the squashing.

> the dependency fixes to the makefile were helpful in general but do you
> want the exactitude I put in for all the whatever.o include,include,
> include, or can you live with me merely slamming $(INCLUDES) as
> a dependency?

I'm afraid the Makefile changes won't get in, since they will make my job
harder, but I don't have time to explain now.  (A bunch of students are
about to arrive in order to renegotiate their grades.  Teaching is 20% of
incredible fun, and 80% of utter boredom.  Just like every fun job,
I guess.)

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] [PATCHes] Misc cleanups to the babeld build system

[Juliusz Chroboczek]

Thanks a lot, Dave.  I've cherry picked the changes that are obviously
correct.

> I am not particularly huge on posting and reviewing patches in-line
> on mailing lists, but I can repost this pull request here, if desired.

Dave, github pull requests are the worst user interface I can imagine.  In
order to cherry-pick your changes, I need to add a temporary remote, pull
a branch, cherry-pick, then delete the branch.  It's absolutely idiotic,
cretinous, and moronic.

Please do some squashing (no need to have half a dozen commits to improve
the makefile), then rebase, then resubmit the remaining patches through
the ML so we can have an adult discussion.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Debugging unreachable routes - IPv6 as next hop?

[Juliusz Chroboczek]

>> Using Lede 17.01 rc 2 and OpenWRT CC I get some unreachable routes.
>> I'm somewhat puzzled. The setup contains 2 nodes sharing a wireless
>> ad-hoc link.

> .. this happened due to a poor wifi link.

Good.  Babel culls asymmetric links, since it's impossible to establish
reliable communication without reliable feedback.  Everything is working
as designed.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] babeldStyle

[Juliusz Chroboczek]

> Is there a specific emacs or vi "c-style" setting I should use while
> hacking on babeld? (.el file would be helpful)

  (setq c-basic-offset 4
indent-tabs-mode nil)

> functions typically start with the { on the first line

Right.  In all other cases, { is on the line of the statement that it
relates to (if/while/else).  } is on its own line, except in the case of
else.  No space between if/while and the opening bracket.  Gotos are used
for error handling, and in some rare cases for error recovery (see the
overflow case in check_xroutes for an example).

> 4 character indent
> 8 characters are usually characters, but there are tabs

They should be spaces; if there are tabs, then I didn't untabify when
applying a patch.  I'm not too religious about spaces vs. tabs.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Debugging unreachable routes - IPv6 as next hop?

[Juliusz Chroboczek]

> Sun Feb 19 17:15:45 2017 daemon.info babeld[1171]: Neighbour
> fe80::227:22ff:fe2e:4153 dev wlan0 reach  rxcost 256 txcost 65535
> rtt 0.000 rttcost 0 chan 1.

It looks like an asymmetric link -- the local node hears neighbour 4153,
but 4153 doesn't hear the local node.  If you manage to reproduce that,
could you please also show the log on the node that advertises the
infinite txcost?

(Note that this can happen if for some reason you're running two instances
of babeld on the same node -- the two instances stomp on each other's
packets, and get confused.  Since OpenWRT/LEDE no longer uses a pidfile,
there is no mechanism in babeld that prevent that from happening.  Please
check with ps.)

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] babeld output on status socket - change neighbour

[Juliusz Chroboczek]

> Under which conditions are rtt and rttcost included?

When we've received a valid timestamp from the neighbour within the last
three minutes (see valid_rtt in neighbour.c).

A zero rtt is strange; could you please send us your configuration?

-- Juliusz


___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] route distribution problem

[Juliusz Chroboczek]

> node2 & node 3 are deliver their routes to node1 and i can see them in the
> routing table or in babelweb (attached screenshot) 10.19.88.0/21 but the route
> that node2 announced is not distributed to node 3.

Plase add

  split-horizon false

to the configuration files.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] route forwarding(?) in mesh VPN

[Juliusz Chroboczek]

> In your case, the problem comes from the split-horizon optimisation: you
> should disable it, because it only makes sense for transitive media.

Right.  Add the following to babeld.conf:

  split-horizon false

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] unicast attempt breaks timestamping

[Juliusz Chroboczek]

>> - extend the IHU timestamp sub-TLV to allow an optional timestamp,
>> perhaps only used when sent over unicast;

> I just checked [1], we should be able to do that without breaking
> interoperability.  Nice.

That's by design.  Draft-jonglez-babel-rtt-extension (of which you are the
first author, I'm just too good) says:

   If the Length field is larger than the expected 8 octets, the sub-TLV
   MUST be processed normally and any extra data contained in this sub-
   TLV MUST be silently ignored.

>> - extend the protocol to allow unicast Hellos.

> I don't see the implications of such a change,

Hellos carry a seqno, which is per-interface.  If we start sending unicast
Hellos, we need to make sure that the seqno of a unicast hello doesn't
cause the seqno counters to get out of sync.  I've got a few ideas, but
I'm not going to do the work myself.  (I reserve the right to change my
mind, as usual.  La consistence est le carcan des petits esprits.)

> Signature made by expired key BE01EC22A04E2E46 Baptiste Jonglez 
> 

Bug in my mailer, or expired key?

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] unicast attempt breaks timestamping

[Juliusz Chroboczek]

>> Based on the patch juliusz supplied me to enable unicast IHU, and
>> 
>> default enable-timestamp true
>> 
>> this stops sending timestamps (which apparently relies on hellos and
>> IHUs being bundled together)

> Can you provide the patch in question?

I cannot find the original patch, but it basically consists in always
taking the alternative (else) branch in the conditional at line 1666 in
message.c.

> Is there any reason why you couldn't send hellos alongside the IHUs?

Yes, Hellos cannot be sent over unicast in the current protocol.  So if
all IHUs are sent over unicast, the timestamps are ignored.

I see two solutions:

  - extend the IHU timestamp sub-TLV to allow an optional timestamp,
perhaps only used when sent over unicast;
  - extend the protocol to allow unicast Hellos.

We could do both.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] some thoughts towards babel-1.9

[Juliusz Chroboczek]

> Well, the rabel repo exists for the crazy ideas... and unfortunately
> testing them at scale tends towards being a PITA.

Exactly my point.  Ideas are cheap.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] some thoughts towards babel-1.9

[Juliusz Chroboczek]

> If that is the only error in two highly speculative documents then I'm
> winning. :)

You'll be helpful (I prefer this to "winning") when you implement some of
your ideas and provide us with hard data to show that they are useful.

(For the record, CS6 and unicast IHU have both been implemented, and
I still haven't seen any hard data that shows that they improve the
behaviour of the network.)

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] another feature request

[Juliusz Chroboczek]

> I think it supports globbing on interfaces (?), which strikes me as
> a useful feature in babeld when interfaces come and go as they do
> nowadays with horrific names like enx2a1c0359e29b as generated by
> systemd. Some way to automagically recognize when an interface (e.g. vpn
> or usb network) comes up that you want would simplify more dynamic
> configurations.

I have no objection in principle, and I'll be glad to review a patch that
does what you want.

Just like Christof, however, I wonder whether this is not better done
outside of babeld.  You could either reconfigure ubus to use rational
names for interfaces (usb0, usb1 etc.), or you could write a utility that
monitors interfaces and speaks to babeld over the control socket to add
them dynamically.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Next Hop TLV meaning

[Juliusz Chroboczek]

> so if I understand correctly, when A sends an Update to B, B needs to know
> address of A and, according to the proper circumstances, B gets address of A
> either from IPv6 packet's source address (case 1) or from The Next-hop TLV
> sent on purpose by A (case 2).

Correct.

>  x y  zw
> A  ---  B  ---  C

> with B that has, in its routing table, an entry for prefix of C with
> next-hop set to w.  I would like that by announcing this route,
> B includes the fact that its selected next-hop is w.

Note that if w is an IPv6 link-local address, it might in principle not be
globally unique, and hence announcing it to A might be ambiguous.  (In
practice, you'll find that your link-locals are unique, though.)

> If I understand correctly what I would call my "next-hop" TLV has a different
> meaning from the RFC one, therefore I should put the info I need into a subtlv
> right?

I'd call that the "second-hop", to avoid ambiguity, and dump it in a new
sub-TLV of the Update TLV.  Just grab a sub-TLV number in the experimental
range:

  https://www.iana.org/assignments/babel/babel.xhtml#sub-tlv-types

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] ANNOUNCE: babeld-1.8.0

[Juliusz Chroboczek]

Dear all,

Babeld-1.8.0 is available from

https://www.irif.fr/~jch//software/files/babeld-1.8.0.tar.gz
https://www.irif.fr/~jch//software/files/babeld-1.8.0.tar.gz.asc

For more information about babeld and the Babel routing protocol, please
see

https://www.irif.fr/~jch/software/babel/

This version includes a new configuration interface, which makes it
possible in particular to add interfaces at runtime without restarting the
daemon.  This is incompatible with the old monitoring interface, and will
require any monitoring software to be modified.

Other than that, some minor changes and correctness tweaks.

-- Juliusz

6 December 2016: babeld-1.8.0

  * Added the ability to reconfigure babeld dynamically from the
monitoring interface.  This is an incompatible change.
  * Changed the configuration language to use an enumerated type instead
of the "wired" boolean.  This is an incompatible change.
  * Setting max-rtt-penalty no longer enables timestamps.  This is an
incompatible change.
  * Added PF_UNIX support to the local interface.  Thanks to Julien Cristau.
  * Made it possible to have a 0 channel number within the diversity extension,
which is consistent with draft-chroboczek-babel-diversity-routing-01.
  * Fixed a bug (introduced in 1.7.0) that could cause spurious policy
rules to be created in the kernel.  Thanks to Matthieu Boutier.

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] babel export routes from bird to routing table?

[Juliusz Chroboczek]

Hi Christof,

> * I am aware that babel 1.8 is not stable yet.

It's stable -- I just need to take the time to do a release.

> As Babel 1.8 will be incompatible to 1.7

Babeld 1.8 will be fully compatible with 1.7.  It's babeld 1.9 which will
change the source-specific routing extension, and that extension only.  If
you're not using source-specific routing (SADR), you won't see any
incompatibilities.

> So babel actually is placing a route in table 10 but not the default route
> that bird has placed in table 12. How would I achieve that?

I think there's a misunderstanding.  Babeld will not copy routes from
import-table into export-table.  It will:

  - announce routes found in export-table over the Babel protocol;
  - install any routes learned over the Babel protocol into import-table.

If there's an unfiltered default route in table 12 (your import-table), it
will be announced to neighbouring nodes, and will prevent babeld from
learning any default routes (since redistributed routes take priority over
routes being learned).

The solution to your problem is to use both tables when forwarding packets,
something like:

ip rule add prio 10 from all lookup 10
ip rule add prio 11 from all lookup 11
ip rule add prio 12 from all lookup 12

If you really need the routes to be copied between the tables, please let
us know why, and we'll see if it's really a needed feature.

-- Juliusz



___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] [babel] feedback this Friday

[Juliusz Chroboczek]

Hi Denis,

The Babel neighbour sensing mechanism is exactly as you describe: if
a given IP address hasn't sent you a Hello, it doesn't exist, and all
packets from it are silently dropped until it sends a Hello.  This is by
design.

You are correct that an IHU does not carry explicit information about
individual hellos, but just a single integer that summarises the link
quality.  That's by design, and that's the reason why IHU is called IHU,
not Ack.

I haven't been able to understand the attack that you outline just from
looking at the slides, so I suggest we discuss it after you've done your
presentation.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Babel User

[Juliusz Chroboczek]

> Hello, I want to ask how babel read the message that send by other node to
> themself ?

Function parse_packet in file message.c.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] alternate source specific encoding?

[Juliusz Chroboczek]

>>> is that in a branch somewhere yet?

>> No, sorry.

> Got an ETA?

Dave, it's September.  Do you imagine what September looks like at university?

> I'm in the process of rebuilding the yurtlab,

Lucky man.  I am in the process of grading undergrad internships. 

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] babel on an otherwise transparent bridge

[Juliusz Chroboczek]

> like it to do is have a dedicated ipv6 ULA ip address for management
> purposes (not using a vlan here), and announce that to the network, but
> never offer itself as a routing opportunity to anything

[...]

> out br-lan something deny?
> in?
> inflate the metric?

out br-lan ula/128 allow
out deny

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] alternate source specific encoding?

[Juliusz Chroboczek]

> is that in a branch somewhere yet?

No, sorry.

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Some minor incompatible changes to the configuration language

[Juliusz Chroboczek]

>> I guess I'll define a new type "conservative" which corresponds to what is
>> done if the interface is not detected as wireless.  Or do you have better
>> ideas?

> Call it "type default" so that there is no preconception, and explain what
> it does in the man page?

Point taken, but I don't like calling it "default" since it's not the
default (the default is autodetection).  Let's think some more.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Some minor incompatible changes to the configuration language

[Juliusz Chroboczek]

>> Split-horizon is *disabled* on interfaces of type "auto", so if you want
>> split-horizon, you should manually set the interface type.

> I'm not sure I get the meaning of "auto", then.  Does it mean babeld will
> auto-detect the interface type (whenever possible, using e.g. netlink to
> look for a wireless interface), or is it just a generic interface type
> with safe defaults?

Yeah, it's confusing.

"auto" means that babeld will attempt detection of a wireless
interface. If it's successful, it will be identical to "wireless".  If the
detection fails, the result is to be "wired" except for split horizon.

I guess I'll define a new type "conservative" which corresponds to what is
done if the interface is not detected as wireless.  Or do you have better
ideas?

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] Some minor incompatible changes to the configuration language

[Juliusz Chroboczek]

I've just pushed some changes that could, in some edge cases, break your
configuration files.  Since I'd like to release 1.8 before the end of the
summer, I'll be grateful if you could test.

First of all, the keyword "wired" is now deprecated (undocumented but
supported for backwards compatibility), you should now say

interface eth0 type wired

or

interface wlan0 type wireless

Possibel types are "auto", "wired", "wireless" and "tunnel", where
"tunnel" enables RTT-based cost estimation.

Split-horizon is *disabled* on interfaces of type "auto", so if you want
split-horizon, you should manually set the interface type.  I'm hesitating
to enable link-quality estimation on auto interfaces -- it would avoid
some wrong configurations, but it carries a significant cost.

The second change is that setting max-rtt-penalty no longer enables
timestamps.  This particular bit of DWIM is no longer necessary now the we
have the tunnel interface type.

I'll be grateful for testing.  I'll also be grateful for any suggestions
that make the interface configuration more automatic.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] A quick summary of babel@ietf

[Juliusz Chroboczek]

Dear all,

IETF is over, we've had the first meeting of the Babel WG.  It went
pleasantly smoothly.  You'll find the full recording of the meeting[1],
the minutes, as well as all the meeting materials, including slides[2].

[1] 
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_BABEL=chapter_1
[2] https://datatracker.ietf.org/meeting/96/materials.html#babel

In short:

  - the chairs said some things;
  - I gave a talk about my plans for evolving the protocol, the audience
seemed to agree;
  - Barbara Stark gave a talk about her proposed management information
model, in which she notably recommended to debloat the model; there
was a short misunderstanding between her and Margaret Cullen, which
was quickly cleared up;
  - Dave gave a talk about routing with hackerboards, a talk that was not
specific to Babel but was well-received and appeared to me to be
eye-opening to at least some audience members.

My feeling right now -- unless we f*ck up really badly, this is going to
be a productive and fun working group.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] [Battlemesh] Reminder: Babel IETF WG meets today

[Juliusz Chroboczek]

> What time zone is that?

CEST, also known as UTC+2.

Unless I got something wrong, that's

  16:20 CEST (Berlin, Paris, Warsaw)
  14:20 UTC
  15:20 BST (London)
  10:20 EDT (New York, NY)
   7:20 PDT (Vacaville, CA)
  11:20 ART (Buenos Aires)


___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] Reminder: Babel IETF WG meets today

[Juliusz Chroboczek]

Dear all,

Just to remind you that the Babel IETF working group is meeting today
for the first time from 16:20 to 18:20 in room Potsdam II.

Remote participation is possible, and appreciated:

  https://www.ietf.org/meeting/96/remote-participation.html

If you've got a decent connection, I recommend Meetecho with Firefox.  If
you're connected at 19.2kbps, I recommend downloading a copy of the slides
just before the meeting, listening to the audio stream, and following the
Jabber channel.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] Reminder: IETF 96 next week, remote participation is encouraged

[Juliusz Chroboczek]

Dear all,

This is to remind you that IETF 96 is next week in Berlin.  There will be
two sessions that should be of interest to members of these lists:

  Homenet, on Monday 18 July at 14:00 in room "Potsdam I";
  Babel, on Thursday 21 July at 16:20 in room "Potsdam II".

Other sessions might be interesting too -- probably MP-TCP, MANET, rtgwg,
perhaps v6ops.  The full agenda is on

  https://datatracker.ietf.org/meeting/96/agenda.html

Remote participation is possible (and very much welcome), please see

  https://www.ietf.org/meeting/remote-participation.html

I recommend using Meetecho with Firefox (for some reason I wasn't able to
get Chromium to work).

If you are physically in Berlin, I couldn't possibly be seen to encourage
you to sneak into the session without paying the (exorbitant) conference
fees.  That would be against the rules.

I might be giving a talk about Babel at Freifunk on Wednesday, but it
hasn't been confirmed yet.  In any case, if you're interested in Babel and
you're in Berlin, I'll be happy to meet.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] [BUG] Route "deadlocks" under load due to non-atomic kernel route updates

[Juliusz Chroboczek]

>> atomic updates in babel,

> Patches gladly accepted.  Or I'll do it at some point, but don't hold your
> breath

Anyone working on that?  Or are you all holding your breath?

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Redistributing /32 routes properly

[Juliusz Chroboczek]

> Which is one more argument in favour of disabling split horizon by default
> in the next version.

Opinions on that?  Does anyone feel that doubling the amount of Babel
traffic on wired links (no change on wireless links) is prohibitive?

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Redistributing /32 routes properly

[Juliusz Chroboczek]

>  For the record, after a chat on IRC Jech helped me out and told me to
>  disable split-horizon processing on the interface (as the routes were
>  all coming in on the same interface). Works great now.   

Which is one more argument in favour of disabling split horizon by default
in the next version.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Why we are discussing ARM [was: Cross-compiling to armhf]

[Juliusz Chroboczek]

> I'd suggest to look into the Familiy of Olinuxino boards produced by
> Olimex: https://www.olimex.com/Products/OLinuXino/open-source-hardware
> or one of their system-on-module boards.

Ah, right.  I recall looking into them, but found their website confusing
(too many models, difficult to find technical information without reading
the schematics).  Which models exactly are you suggesting we look into?

Do you know how the Ethernet is hooked to the SoC?  I could be wrong, but
I don't think Allwinner SoCs include GMII.

Do they use upstream kernels, or their hacked up tree?

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] rib out of sync

[Juliusz Chroboczek]

>> repeatedly failing and restoring an interface (ifconfig down/up),

This is a known issue, Dave.  The code that checks for interface down/up
events is racy, it can get confused if you do up/down/up and it doesn't
trigger before the interface gets back up -- it thinks that nothing
changes.

The code is in if_up in interface.c, and I don't see a good way of fixing it.

> I stepped back to 1.6.3 and the kernel and babel ribs stayed correct
> no matter how much I upped or downed the usb0 interface while keeping
> the wifi alive.

Hmm, there have been some changes to this code in February, I'll have
a look to see if I could have increased the vulnerability window.

Thanks for the report, Dave.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

[Babel-users] Fwd: [babel] babel - Requested session has been scheduled for IETF 96

[Juliusz Chroboczek]

--- Begin Message ---
Dear Donald Eastlake,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

babel Session 1 (2:00:00)
Thursday, Afternoon Session II 1620-1820
Room Name: Potsdam II size: 175
-



Request Information:


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

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



Special Requests:
  
-

___
babel mailing list
ba...@ietf.org
https://www.ietf.org/mailman/listinfo/babel

--- End Message ---
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] Cross-compiling to armhf [was: beaglebone green wireless boards...]

[Juliusz Chroboczek]

> the long slow EABI changeover that was obsoleted almost overnight by the
> armhf work the raspian folk did, and so on.

I am pretty positive that armhf predates raspbian.  Let's please give
credit where credit is due.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users