Re: [homenet] HNCP: interaction with routing protocol?
> 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: interaction with routing protocol?
>> 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. > Just redistributing protocol 43 will also make you miss the default > 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Babel-users] Detecting bridges
>> I.e., a router on wifi announces wifi and when a router that is on wired >> receives an announcement from a router on wifi it knows that there >> a bridge somewhere. > >Not a bad idea, but I'm a little hesitant to implement that, since it >would require defining a taxonomy of interface types at the protocol >level. (Currently the taxonomy exists in the implementation, but it >doesn't appear in the protocol -- the protocol only knows about metrics.) It is probably not such a good idea to literally say 'wifi', but if a set of metrics could be defined that describe that expected stability of a link then a router could annouce which it has configured or discovered. One thing to consider though, in my experience lossy links make for a very bad user experience. So if a disconnect happens as a result of user action, say moving a wifi device from one room to another, then losing the link is not a bad deal. If links just come and go then ultimately users will just complain that the internet is bad. If bad links are unavoidable, it is better to run a tunneling protocol on top of those links with forward error correction or other mechanism to make the link more reliable. (I.e, it might better if babel degrades gracefully, instead of trying to make bad links 'work') ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Babel-users] Detecting bridges
On 18.12.2015, at 11.53, Juliusz Chroboczek wrote: >> Is there room in the protocol for a router to announce what link type it >> is on? > This could be carried by a sub-TLV of Hello (or a sub-TLV of IHU if you > want to make it per-host). > >> I.e., a router on wifi announces wifi and when a router that is on wired >> receives an announcement from a router on wifi it knows that there >> a bridge somewhere. > > Not a bad idea, but I'm a little hesitant to implement that, since it > would require defining a taxonomy of interface types at the protocol > level. (Currently the taxonomy exists in the implementation, but it > doesn’t appear in the protocol -- the protocol only knows about metrics.) I am somewhat suspicious about the idea too, although for different reasons. Notably, most things that run routing protocol these days use ethernet plugs for them (+- some wireless ad-hoc people). Even if I have ‘modern cheapo router’ on both ends of a powerline bridge, odds are, it is just using ethernet plug. So link type autodetection is out of the window, and if I manually need to specify that this ethernet is really powerline, I might as well configure the routing protocol, and I find both ideas non-appealing. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: interaction with routing protocol?
On Wed, Dec 16, 2015 at 6:31 PM, Juliusz Chroboczek wrote: >> 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. Just redistributing protocol 43 will also make you miss the default route you get by DHCP from an uplink. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Babel-users] Detecting bridges
> Is there room in the protocol for a router to announce what link type it > is on? This could be carried by a sub-TLV of Hello (or a sub-TLV of IHU if you want to make it per-host). > I.e., a router on wifi announces wifi and when a router that is on wired > receives an announcement from a router on wifi it knows that there > a bridge somewhere. Not a bad idea, but I'm a little hesitant to implement that, since it would require defining a taxonomy of interface types at the protocol level. (Currently the taxonomy exists in the implementation, but it doesn't appear in the protocol -- the protocol only knows about metrics.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
