On Aug 5, 2015, at 1:01 PM, Dino Farinacci <[email protected]> wrote: > Let’s just keep the discussions technical.
This is a great sentiment, but in fact on a technical level there is no reason to prefer Babel(now) over IS-IS(later). Nobody is making the claim that IS-IS can’t be tweaked until it performs as well as Babel on a homenet. The claim is that it doesn’t work well now, and it would be a new research project to fix it so that it does work. Of course, your entirely just rejoinder to this will likely be “can you prove that Babel(now) works better in the homenet context than IS-IS(now).” And for that the only response that I think is particularly convincing is that Babel is in active use in this context now and is working, and in addition that it has been extensively tested in battle-mesh meetings, and does well in that context (there are some open source competitors that also do well, but none are candidates for homenet because they don’t have RFCs that document them). Battle meshes are not exactly like homenets, but they test the hell out of the case where Babel and IS-IS differ in their ability to support routing on the homenet. If we had a smoking gun that showed that one protocol was decisively better than another, we already would have come to consensus. I agree with Michael’s subsequent comment on this thread, though, and would add an additional point. It is not the case that when half the working group wants one thing, and the other half wants a different thing, that we do not have consensus, because consensus is not voting. Working group chairs often refuse to _call_ consensus when that situation prevails, or else don’t realize that they can, but they are not forbidden to do so. Indeed it would save a lot of time if they did so now, and I think they reasonably could. Dave Thaler did this last year in the PCP working group, and it was a very successful move that put an end to a really time-wasting dispute over trivia. A dispute, I might add, that was very similar to this one. It is not a simple process, and definitely isn’t a matter of a chair picking their favorite. Dave did a lot of homework to describe the process he went through to make the decision. The losing team was pretty pissed off, but they couldn’t really argue with the process, and as a result did not appeal. IMHO this is actually better than tossing a coin, and I wish more working group chairs would do it. Putting the responsibility for breaking the tie on a design team or on some magical future instance of the working group that has changed its mind (which is really what a requirements doc is going to do) is just kicking the ball further down the road.
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
