> Which, if any, of the currently defined extensions should be merged into the > base spec? My opinion is that the extension mechanism should be merged, > but that the actual extensions should remain separate documents.
I would agree with this assessment -- the extension mechanism should be merged in the base doc, but any actual extensions should be managed separately. I would say each proposed extension needs a pretty clear use case, a specification, and then an implementation report (if available), and possibly some form of deployment experience draft (if available). Smaller, more focused chunks are better than the long many page documents we've been seeing a lot of recently. > RFC 6126 states that designing a route selection algorithm for Babel is an > open research problem. While this is still true, there should be an > informative appendix that describes the trivial algorithm (just pick the route > with the lowest metric) and the time-sensitive algorithm used since version > 1.4.0 of babeld since it is simple and appears to work well in practice. Yes, definitely. Note that choosing a route across two metrics is, as I understand it, unsolvable. This is the reason EIGRP uses the K values to merge the metrics the user would like to actually deploy into a single metric. Note also there needs to be some way to prevent oscillation between the control plane and the data plane when you start playing with delay, bandwidth utilization, etc., in the real world. These are nasty problems. > Incompatible protocol changes > ============================= > > A Babel packet carries a protocol number, which it is possible to increase if > the protocol needs to change in an incompatible version. I'd be opposed to > doing that, since it would severely impact the installed base of Babel routers, > and could cause a split in the community, as has unfortunately happened > with the OLSR community. A protocol version? It would be simpler to have some sort of capabilities negotiation here, possibly. > Adding mandatory and transitive bits, as in BGP > ----------------------------------------------- > > There is currently no way to mark a sub-TLV of an Update TLV as mandatory, > as in BGP. This has forced us to design the source-specific extension as using > a separate TLV, which is not very elegant. However, the source-specific > extension would still have required new TLVs for requests. > > Mandatory and transitive bits would make it easier to design an extension > that does BGP-style communities that are suitable for filtering, a feature that > has been requested by both the Italian and Slovenian communities. > > I believe that the doubtful benefits that this provides do not justify an > incompatible protocol change. I would disagree... It's better to have some way for a device receiving an update if it should ignore and potentially send an error, or if it should try and process. If you don't have mandatory bits, then you don't have a way to error out of a neighbor relationship. This means the receiver can either just bounce the relationship and refuse to peer, which is really hard to troubleshoot, or it can accept and ignore, which can also be really hard to troubleshoot. > Source-specific routing uses its own set of TLVs, which are distinct from the > base protocol's TLVs. Merging the two kinds of TLVs would yield a slightly > cleaner protocol, but would require putting source-specific routing in the > base spec. I like small specs. I would keep the specs separate, myself. > * lower-layer security (e.g. put a frightening guy or gal with > a truncheon in front of each Ethernet plug, or use 802.1X); > * HMAC authentication (RFC 7298); > * Stenberg-style authentication (move everything to unicast except > hellos, use DTLS); > * use the replay protection from RFC 7298 together with statically keyed > IPsec. > > There are different tradeoffs between these techniques (reuse of existing > libraries vs. compact code, authentication only vs. privacy, etc.), so the > current plan is to implement them all and let the community decide. I am > therefore strongly opposed to putting any security mechanism in the base > spec. I would allow separate development in this area -- but it does need to be done. I would look at requirements and solutions, and make a single decision. Otherwise you fragment the implementations, as not every one of these is as easy to implement as it might seem, and you might find holes that need to be fixed in all four at some point. A single solution is better, IMHO. :-) Russ _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
