Martin Mares <mj@ucw.cz> writes:
Hello!
Yes, and have 2 binaries for those protocols. Very funny. :-(
I don't see any reason to make 2 binaries, when architecture of your programm can easily support both protocols.
The decision whether to support both protocols in a single binary or not was very hard, but I don't regret what we had chosen. Else we would get a ton of extra complexity in all the interfaces and data structures, all addresses would have to be tagged with address types, route entries would have to be either sized dynamically or according to the largest address type used, leading to much slower and space consuming result. In fact, I think this was one of the principial design failures of Zebra.
Also, IPv4 and IPv6 are two worlds which have only a little in common, namely the network interfaces they live on, hence it makes very little sense to combine them to a single program.
Ok then. But when doing ./configure you say --enable-ipv6 . No even a simple word about effectively disabling ipv4 :-(
Otherwise, there should be 2 binaries with different names - because they do 2 different things.
bird-ipv4 and bird-ipv6
Think about adding BIRD to for example Debian distribution. If there is only one name of this daemon, you have to create 2 conflicting packages bird-ipv4 and bird-ipv6.
I see no problem in distributing bird as packages "bird" (with /usr/sbin/bird), "bird-ipv6" (providing /usr/sbin/bird-ipv6) and "bird-doc" providing the documentation. No conflicts there.
Could you please make this change in your package? I mean, when generating bird-ipv6 call it bird-ipv6 and make it read config file etc/bird-ipv6.conf and use different socket for communication with bird client. I have also got a comment about export and import keywords. I don't think it is a good idea to call it this way. These keywords are a part of protocol statement, so "export" semantic is to export routes originating in this protocol to routing table - you call it "import". It is really confusing me. -- ------------------------------------------------------------------------- David Rohleder davro@ics.muni.cz Institute of Computer Science, Masaryk University Brno, Czech Republic -------------------------------------------------------------------------
Hello!
Could you please make this change in your package? I mean, when generating bird-ipv6 call it bird-ipv6 and make it read config file etc/bird-ipv6.conf and use different socket for communication with bird client.
Good idea, I'll do that.
I have also got a comment about export and import keywords. I don't think it is a good idea to call it this way. These keywords are a part of protocol statement, so "export" semantic is to export routes originating in this protocol to routing table - you call it "import". It is really confusing me.
Agreed. The problem is that the situation is completely symmetric, so any naming you choose has to be a bit confusing -- it's the same as defining left and right hand. We have chosen "bird-centric" view, hence "export" means "export from bird to the outside world" and "import" the opposite. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Every program in development at MIT expands until it can read mail.
Date: Tue, 27 Feb 2001 11:30:26 +0100 From: Martin Mares <mj@ucw.cz>
I have also got a comment about export and import keywords. I don't think it is a good idea to call it this way. These keywords are a part of protocol statement, so "export" semantic is to export routes originating in this protocol to routing table - you call it "import". It is really confusing me.
Agreed. The problem is that the situation is completely symmetric, so any naming you choose has to be a bit confusing -- it's the same as defining left and right hand. We have chosen "bird-centric" view, hence "export" means "export from bird to the outside world" and "import" the opposite. I remember the confusion when trying bird for the first time (alas, my needs have shifted, I'm now on a very static stub). The above paragraphs really clarified the situation nicely, perhaps they could be added to the documentation (without much change, the wording was excellent) ?
participants (3)
-
David Rohleder -
Martin Mares -
Network Administration