Subject: [homenet] HNCP: interaction with routing protocol?

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 13 Dec 2015 19:14:02 +0100

I'm probably missing something -- but where in the HNCP document does it
say that applied prefixes must be announced over the routing protocol?
I don't see it in Section 6.3.3.

-- Juliusz

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 13 Dec 2015 20:37:02 +0100 (CET)

> I don't see it in Section 6.3.3.

I'd say the role of HNCP and the routing protocol and what does what, is 
not really specified anywhere.

Otoh, it's very natural for me that a routing protocol would do 
"redistribute connected" or at least do this for interfaces marked as 
"HNCP". From my testing before on the actual OpenWRT implementations as 
they are configured out of the box as I tested them, it seemed babel was 
doing "redistribute connected" for all interfaces, and the isis zebra 
implementation was only doing this for HNCP marked interfaces. What the 
right thing to do here should probably be a SHOULD somewhere, but I'm not 
sure the HNCP specification document is the right place to do it.

It would probably make sense to have a document that defines what the 
routing protocol does. We've had discussions here before where assumptions 
have differed between different participants in the group...

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 13 Dec 2015 21:59:01 +0100

> not really specified anywhere.

HNCP does specify when the router MUST speak RA and DHCPv4, and SHOULD
speak DHCPv6-PD, so I'd expect it to have similar requirements for
routing.  It doesn't make a lot of sense to send RAs or perform prefix
delegation if you're not going to announce the prefix over the routing
protocol.

Markus, Stephen -- it's too late to change that, right?  If so, no big
deal, we'll put it in the Homenet profile for Babel.

> doing "redistribute connected" for all interfaces,

The OpenWRT hnetd configuration redistributes everything, indeed.  The
recommended shncpd configuration redistributes just hncpd routes:

    redistribute local deny
    redistribute proto 43 allow

("redistribute proto 43" is shncpd, "redistribute local" is locally
assigned addresses.)

(I'll go out on a limb, and argue that it's not HNCP's business to say
what the routing protocol does with non-Homenet routes -- it's hopefully
legal for a Homenet router to redistribute, say, RIPng into Babel --, so
both implementations are correct.)

-- Juliusz

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 14 Dec 2015 07:15:07 +0100 (CET)

>    redistribute proto 43 allow

Just to be clear here, when you say "hnetd configuration" you are 
referring to babeld.conf that gets installed when you install hnetd-full? 
So it's really the babel configuraton that you get when installing hnetd?

Because as far as I understand, hnetd doesn't do any redistribution into 
the routing protocol, this is done by configuring the routing protocol to 
look at interface addresses/prefix and communicating this to other 
participants in the routing protocol?

hnetd does address configuration on interfaces, the routing protocol 
picks this up because that's how it's configured...? Hnetd doesn't 
communicate directly with the routing protocol at all, right? It just sets 
up the landscape so the routing protocol can come and survey it and 
communicate the contents.

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 14 Dec 2015 13:59:10 +0200

> On 14.12.2015, at 8.15, Mikael Abrahamsson <[email-masked]> wrote:
> 
> Just to be clear here, when you say "hnetd configuration" you are referring to babeld.conf that gets installed when you install hnetd-full? So it's really the babel configuraton that you get when installing hnetd?

The routing support script that enables routing on an interface (based on border discovery result) has hard-coded configuration for Babel which redistributes all routes.

> Because as far as I understand, hnetd doesn't do any redistribution into the routing protocol, this is done by configuring the routing protocol to look at interface addresses/prefix and communicating this to other participants in the routing protocol?
> 
> hnetd does address configuration on interfaces, the routing protocol picks this up because that's how it's configured...? Hnetd doesn't communicate directly with the routing protocol at all, right? It just sets up the landscape so the routing protocol can come and survey it and communicate the contents.

See above. Given fixed interface categories, static routing protocol configuration could work, but as is, the script provides list of interfaces that routing protocol _can_ run on given the current state of detected borders.

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 16 Dec 2015 18:31:13 +0100

> hnetd does address configuration on interfaces, the routing protocol picks
> this up because that's how it's configured...? Hnetd doesn't communicate
> directly with the routing protocol at all, right? It just sets up the
> landscape so the routing protocol can come and survey it and communicate
> the contents.

That's exactly right (and very well put).  That's what I tried to express
in my talk at Prague -- it turns out that HNCP is a very clean design.
(Except where it isn't, of course.)

Hnetd and shncpd do that somewhat differently.  Hnetd assume that the
routing protocol redistributes everything.  Shncpd has closer binding to
the routing protocol, it marks its routes as "proto 43" and expects the
routing protocol to redistribute just that; shncpd also occasionally
inserts dummy "proto 43" routes into the kernel, just so that they get
redistributed into the routing protocol.  The result is that shncpd
produces somewhat cleaner (more aggregated) routing tables, at the cost of
requiring special configuration of the routing protocol.

(Why 43?  Because babeld uses 42, of course.)

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Fri, 18 Dec 2015 12:20:09 +0100

> requiring special configuration of the routing protocol.

Just redistributing protocol 43 will also make you miss the default
route you get by DHCP from an uplink.

Henning Rogge

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 18 Dec 2015 16:15:37 +0100

>> Shncpd has closer binding to the routing protocol, it marks its routes
>> as "proto 43" and expects the routing protocol to redistribute just
>> that; shncpd also occasionally inserts dummy "proto 43" routes into the
>> kernel, just so that they get redistributed into the routing protocol.

> route you get by DHCP from an uplink.

If you're announcing an external connection into the HNCP domain, shncpd
will install a proto 43 source-specific default route.  See route_externals
in prefix.c.

If you're not announcing an external connection, then indeed you need to
manually arrange redistribution of the default route.  Shncpd doesn't do
that for you, since it doesn't know whether forwarding is set up for the
route and whether there's the need to set up a source prefix for BCP38.

(This is where hnetd and shncd differ.  Hnetd is optimistic, it assumes
that forwarding is set up and that the default route has a suitable source
prefix attached.  Shncpd is pessimistic, and fears that redistributing
random default routes into the routing protocol will create blackholes.
Somebody once wrote that optimists and pessimists die the same way, they
just live differently.)

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 18 Dec 2015 16:20:59 +0100

> will install a proto 43 source-specific default route.  See route_externals

In case that wasn't clear -- shncpd doesn't act as a DHCPv6-PD or DHCPv4
client, it expects you (the human operator or the startup scripts) to set
up what HNCP calls an "external connection" using the "-E" and "-N" flags.
So the design is the opposite of hnetd: hnetd controls the DHCP clients,
while shncpd is controlled by the DHCP client.

Depending on whether you already have suitable DHCP clients in your
system, you'll prefer one approach or the other.

-- Juliusz