[Babel-users] althea presentation on isp in a box at nanog 76

[Justin Kilpatrick]

> Justin, could you please document the private TLVs that you're using and
> register them with IANA?  (I'm currently under pressure to make the TLV
> allocation more onerous, and yours is a good example of why requiring an
> RFC for every Babel extension is a bad idea.)

I actually have mostly written RFC's for both. 

https://github.com/althea-net/babel-drafts/blob/master/draft-ietf-babel-full-path-latency/draft-ietf-babel-full-path-latency.xml
https://github.com/althea-net/babel-drafts/blob/master/draft-ietf-babel-price-propagation/draft-ietf-babel-price-propagation.xml

I'm using 45 for the full path latency subtlv

https://github.com/althea-net/babeld/commit/ad97f266ff08f0d31ab554152f63a28b3d14fca2

The price updates are hacked onto the update tlv as we aren't running the price extension I specified. which is why I advertise a different protocol number for now. I do hope to upgrade to the full spec version of the price advertisement at some point. 

I've been conflicted over making full path packet loss it's own TLV or not. You can derive it from the metric field if all nodes are configured 'the althea way' but that's very much not spec behavior. So I should probably bite the bullet. 

If the general protocol registry form on the IANA site is appropriate than this shouldn't take but a few minutes. I think 45, 46, and 47 are all available right?

> You're running Wireguard over Babel or the other way around?  Any issues
> with that?

We're running Babel over WireGuard and WireGuard over Babel. The bottom layer for authenticating packets between peers and the top for securing user traffic as it traverses the network.

The biggest roadblock was the lack of unicast peer discovery back when I wrote the neighbor discovery and neighbor tunnel creation system.

Wireguard follows this concept of allowed ip's. So if I have tunnel wg0 with a peer A, that peer can only use packets with src 1.2.3.4. This is a problem for babel where every instance wants to use the same mulicast address. We solved this problem by spinning out several tunnels on different ports. 

I think now we could condense this by configuring unicast peer discovery which from what I understand is in master. 

Which would be great, the logic for dynamic port allocation to peers is quite hairy. 

Everything else with routing or link state detecting works flawlessly with no issues.

Oh yeah the default number of management connections is puny, I bumped it to 128, might want to make it configurable. 

The final thing on my wishlist is just a Rust Babel implementation. It's such a pleasure to write in, very easy to get your code to the point where if it compiles it works. Chances are we'll make one ourselves eventually. 

-- 
  Justin Kilpatrick
  justin at altheamesh.com

On Thu, Jun 20, 2019, at 12:00 PM, Juliusz Chroboczek wrote:
> > Interesting stuff - wireguard, fq_codel/sch_cake, babel with new
> > metric that allows for cryptocurrency traffic billing.
> 
> Justin, could you please document the private TLVs that you're using and
> register them with IANA?  (I'm currently under pressure to make the TLV
> allocation more onerous, and yours is a good example of why requiring an
> RFC for every Babel extension is a bad idea.)
> 
> You're running Wireguard over Babel or the other way around?  Any issues
> with that?
> 
> -- Juliusz
> 
> _______________________________________________
> Babel-users mailing list
> Babel-users at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users