This is very simple to resolve. This is not a technical response. (1) Have homenet adopt both protocols. Let the market decide. That means there may be routing protocol redistribution in the home. This would be a mistake.
(2) Pick one and move on. This has a chance of working if open source is available because vendors will take the quick-approach into delivering a solution. We saw this work with SNMP in the 90s (but this wasn’t an open-source case but a single reference implementation case). (3) Pick one and hope it catches on. Vendors, if they have vision will say the chosen one was BS, and they will do their own. That means there may be routing protocol redistribution in the home. This would be a mistake. Just pick one and hope (2) prevails. And we know from experience that whatever is chosen will be tweaked to adapt to new requirements or fix unanticipated problems. Dino > On Aug 5, 2015, at 10:26 AM, Ted Lemon <[email protected]> wrote: > > 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
