Re: [homenet] New Version Notification for draft-howard-homenet-routing-comparison-00.txt

[Jari Arkko <[e-mail]>]

Lee,

I have to send a more in-depth review of your draft later, but just touching on a couple of important points:

> The problem with zOSPF is that it doesn't meet our requirements. It doesn't detect borders (unless the border happens to have another zOSPF router with the wrong password), 

The problem is that we have incomplete proposals, and people are making evaluations based on assumptions on what those incomplete specification or implementation parts might be. We also have a _system_, not an individual protocol, and several protocol implementation modules need to co-operate so that the system delivers the desired behavior. For instance, if we think about the home network as a black box, it needs to talk to external world probably at least with DHCP and DHCP-PD, talk to hosts within the network with ND, do something for naming and discovery protocols, etc. Internally, it may do something black box magic for the routing and other things, of course.

A case in point. I'm working on an implementation that most definitely detects borders, and still uses OSPF autoconfiguration to handle routing. How does it detect borders? It attempts to do DHCP, DHCP-PD, OSPF autoconfiguration, and the usual "I have a working connection to the Internet" probing techniques. It also allows for manual configuration, or the "this port is for Internet, the other one is for internal network" models.

> it requires configuration (for the password),

Acee's autoconfiguration design is nice in that it can be guaranteed to not accidentally connect to enterprise and ISP networks simply due to the selection of the area and instance IDs. See Section 2 in draft-acee.

I think it would be useful to provide an automatic security model on top of the autoconfiguration design, and some ideas for that have been circulated on the list. But I would think that the security model and issues in setting it up are very similar between different routing protocol-based designs and with the PIO design. For instance, we can provide ssh-like security relatively easily, but if you want to go beyond that then you must have configuration.

> it doesn't handle walled gardens (a requirement being debated), it's not lightweight. 

I agree that link state routing protocols are a bigger amount of code than, say, RIP. But I think the crux is code availability and reliability, rather than pure measurement of lines of code. Most home network vendors would use an openly available implementation rather than write their own, so having one available is more important than the number of lines in it. I think I have seen the working group favor support for complex topologies, preventing user action from leading to non-working network more than for absolutely simplicity. I think for absolute simplicity and code availability, RIP could be our choice.

Jari