[homenet] comments on draft-howard-homenet-routing-requirements

[Jari Arkko <[e-mail]>]

Thanks again for writing this document. A couple of comments:

In general, I agree with almost all of the requirements. A couple of discussion points, however:

#rant on

I think we as a group as pretty over-focused on multihoming and I'm not sure I buy the "multiple upstream networks" requirement in its entirety. I don't have a better suggestion, and I know many people in the group have talked about things along these lines. However, as a reality check, I'm aware of only a handful of people (myself included) who actually run multihomed networks in their homes. Within that set of people, most seem to be doing it in some more special way rather than as a general-purpose hot-standby multihoming network (myself included). I'm also concerned that since our WG consists of many well-known multihoming hopefuls from various IETF efforts over the years (myself included), that we are taking our own wishes more than the reality as a basis of our design.

In particular, what I *do* see being very widely deployed is separate networks. I have plenty, for instance, because my utility providers want to do their own thing and they just don't trust my networks. They have their own device/router, own uplinks. I think we will see more of this in the coming years as smart grids etc. are coming online. But the multiple upstream networks requirements says very little about this case. But I think it would be possible to provide better support for using shared infrastructure, yet different networks in a home setting. I just don't think we would necessarily think about that in the light of destinations and sources addresses... perhaps more in the light of separate VLANs, separate OSPF instance IDs, and so on.

All that being said, I think the statement from the interim which said that we should offer the ability to have multiple upstream links was useful. Still, I think those requirements are more in the optional category.

#rant off

The looping requirement avoids the interesting details. "Prevent" or "live with"? Any topology? Personally, I'm in James Woodyatt's camp and believe that we must survive trial-and-error plug-in exercises by the users.

The requirements draft did not talk about walled gardens. From the comparison draft 6F, I had trouble understanding what exactly is required. I also do not personally believe we should go out of our way in the IETF to support walled gardens.

Jari