Re: [homenet] Thoughts about routing - trends
On 10/12/11 7:51 PM, Russ White wrote: [...] While I wouldn't want to rule OLSRv2 completely out, I think it should compete head to head with an extended OSPF and an extended IS-IS, or even other efforts afoot. I'd rather see requirements first, and a good solid evaluation of what's available against those requirements, rather than choosing technologies out of the gate. Hi Russ, I fully agree. There should be an evaluation against the requirements. My point was just not to rule out OLSRv2 (or other protocols) based on the fact that a protocol is used, amongst other, in mesh network deployments. Ulrich ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing - trends
Hi Jim, I fully agree with you. Declaring OLSRv2 etc. out of scope just because a home is not a mesh network seems simplistic to me. As you explained in your mail, many of the problems that mesh networks already solve successfully today, can be very similar in a home: dynamic topology, no skilled network operator centrally managing the devices, wireless and wired devices, limited resources on the routers etc. These were exactly the motivation for developing such protocols in MANET. Best regards Ulrich On 10/12/11 3:10 AM, Jim Gettys wrote: On 10/07/2011 03:48 AM, Fred Baker wrote: 4) The use of OLSR in mesh network scenarios Jim Gettys commented on the fact of OLSR use. The general sense of the room was that OLSRv2 is interesting but out of scope for this discussion as mesh networks are quite different from typical residential and SOHO networks. Actually, I have no opinion of OLSR, Babel, Babelz or OSPF; it's not my area of expertise. Babel/BabelZ is appearing in CeroWrt today as the people who are interested in such things are doing the work (we don't need a routing protocol in the simple single home router case), and it provided the functionality we needed. For those who want something else, quagga is in the CeroWrt build for your hacking pleasure. And I'm not advocating the homenet working group do anything unusual about routing at this date; as I said, it's not my area of expertise. Having said this, I do note the following technological trends: 1) As soon as we get real plug and play routers that don't need manual configuration that work, we'll see a lot more routers in a home environment. Other radio technologies (e.g. zigbee) may encourage this trend. It seemed like the working group agreed that getting to the point that just hooking things together would really just worked was a fundamental requirement (and I agree entirely with this sentiment, as it reflects reality of what already happens in the homes of hackers and non-hackers alike). 2) wireless is much cheaper to implement than wired networking, particularly in most houses where pulling cable is hard. I know this first hand, where I've pulled a lot of cat 6 and wish I could get it to places I don't have it. Unless power line networking really works, I believe that this trend isn't going to change. Is there any progress in this area? I've seen many promises, and few reliable working products. 3) As soon as you have two routers, you have at least two paths; the wired connection between them and the wireless. You may have 3 paths, if you have both 2.4 and 5ghz radios. Frequency diversity routing becomes immediately interesting, along with using your ethernet when it's available in preference to wireless. 4) an apartment building look like a mesh, and possibly with multiple backhauls possibly with multiple ISP's. One should at least think about what happens when you have homes, in such a building, and make sure nothing breaks. Wireless is messy: it isn't limited to where a wire goes. Taking down an entire apartment building/blocks/city would not be fun. I know, I've been there (at least to the point of taking down buildings, and came within a week of a much larger scale disaster). If you believe 1 + 2 + 3 +4 (as I do), then if you look a few years out, you end up with something in the home that begins to resemble very strongly what the community mesh networking folks are doing at a higher scale geographically and in terms of # of nodes today, with many/most of the same concerns and solutions. Understanding the problems they've faced/are facing is therefore worth a bit of investment; Radio diversity is one of the concerns, and interference (of various sorts). Julius' talk about why frequency diversity is an issue is here: http://www.youtube.com/watch?v=1VNzm0shSA8 While the issues outlined above are not where home networking is today, my gut feel is they will be in five years. If there is *anything* I can urge on the group, is to respect the scaling problems that can/will occur, and to internalise wireless !=wired: wireless goes where wireless goes and does not behave like ethernet. The group needs to ensure nothing bad happens when people start building systems in ways you don't expect, particularly in an apartment building. The challenge is balancing the reality of how wireless works, with just works automatic configuration, with fail safe behaviour. - Jim ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing
Hi, On 10/12/11 8:38 AM, Michael Richardson wrote: Russ == Russ White ru...@riw.us writes: Russ You need a unique identifier at the equipment level for Russ anything you intend to auto-configure --autoconfiguring Russ uniqueness is a very hard, probably impossible, problem on a Russ global scale. So we need to count on this one thing, no matter Russ what else we might need to back in to. Russ Now, it might be possible to some hash over a GPS location for Russ a base, and then add on MAC addresses, or some such, but We've assumed a unique MAC, which is 48 bits long. But OSPF router-id is 32 bits.What is the likelyhood of a collision in the bottom 32-bits of the MAC? It seems to me that this discussion about duplicate addresses / unique MAC tool already place in the IETF a number of years ago, e.g. as reflected in RFC 4862 (IPv6 Stateless Autoconfiguration, section 5.4), where duplicate address detection is mandatory. It wouldn't have to be if the assumption holds that all MAC addresses are unique. Even though the probability of collisions may be low, because of manufacturer errors / virtual interfaces and virtual machines / reduction from 48bits to 32bits, there could be collisions. I am not convinced that we can make Russ' assumption that we need unique identifiers at equipment level (or at least that seems inconsistent with previous IETF decisions, so we would need to make a strong case what has changed since then). I do agree with Russ, though, that verifying uniqueness is hard. Regards Ulrich ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing
Jari, On 10/11/11 12:05 PM, Jari Arkko wrote: Home routers would also have MAC addresses, but again, if we need a 32-bit quantity then shortened 48/64 bit identifiers may (theoretically) have collisions. That being said, if the home routers have to discover their IPv6 prefix through a protocol and store it in flash, they could probably do so also for a router ID. Unless there was some chicken and egg problem that required the router ID for all this discovery to work... I agree. Since we need to configure unique prefixes to each router in the home anyway, it should not be any problem to do the same for a router ID (or even just use an address from the configured prefix as router ID, which should then be unique). A while ago, there were some plans in AUTOCONF to specify how to use DHCPv6 (-PD) in a multi-hop network for configuring prefixes in the network. As in a home network, I assume there is always at least one border router with the global prefix, specifying something like that seems to be reasonable for me (in a MANET, that can be more difficult, because there is not necessarily such a central entity as the border router). Regards Ulrich ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] liasons and cross posting (was Re: Question for you)
Hi Curtis, Sorry for my off-topic email: On Thu, Oct 6, 2011 at 11:40 AM, Curtis Villamizar cur...@occnc.com wrote: [...] btw - this message is cross posted to three lists: homenet, manet, rtgwg. I suggest we drop the cc to homenet only and anyone on rtgwg and manet can join homenet and continue the discussion. Actually, I would prefer to limit it to one mailing list (e.g. homenet). As many, like you, are not subscribed to MANET, the MANET chairs or I have to accept each reply manually because of the mailing list filters (and currently, there are several emails per day). I have sent an email to the MANET list that the thread is continued on homenet only, so everyone interested in the topic may follow the thread there. Best regards Ulrich On Oct 5, 2011, at 11:24 AM, Joe Touch wrote: -1 The charter already allows for interface to external groups: --- The working group will also liason with external standards bodies where it is expected that there are normative dependencies between the specifications of the two bodies. --- I.e., this can be handled via liaisons (better, IMO). Joe On Oct 1, 2011, at 5:20 PM, Fred Baker wrote: On Oct 1, 2011, at 10:38 PM, Don Sturek wrote: To add one more point to Fred's note: I think it is important to get a commercial group like Wi-Fi to participate in Homenet, adopt some or all of the drafts/RFCs then sponsor interoperability testing. That would be very interesting. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [manet] Question for you
Hi Tony, I agree. I would like to mention that we are specifying an extensible, flexible (using TLVs) LS protocol in the MANET WG: OLSRv2. I think that we are not far from submitting it to the IESG. OLSRv2 could well operate on home devices with limited resources, and does not have the issues of RIP. Regards Ulrich On Mon, Oct 3, 2011 at 9:15 AM, Tony Li tony...@tony.li wrote: The problem with a RIP like protocol is that it will have RIP like convergence properties. IMHO, that's no longer acceptable. Doing a subset of a LS protocol with a trivial default configuration should not be unreasonable. Tony On Oct 3, 2011, at 8:58 AM, Randy Turner wrote: I would hope that we would NOT be seriously considering OSPF or IS-IS in the home...this seems like using a sledgehammer to kill an ant. How many routes are we talking about for a home network? I don't believe any enterprise routing protocol was designed for a zeroconf or zeroadmin type of environment. Our customers won't even know what an IP address is. Seems like a RIP-like (around the same scope of complexity) would be enough for a homenet. I'm curious to see what comes out of the LLN discussion. The filter for any of these decisions should probably always be a zeroconf or zeroadmin scenario -- if a proposed approach to a problem can't exist in a zeroconf/admin environment, then I would think it would not be the right choice. Also, as a first cut solution, we I think we should be focused on the 80% use-case, not the fringe. The participants of this working group, and their respective home networking setups, are probably not our typical customer. Randy On Oct 3, 2011, at 8:33 AM, Qiong wrote: Hi, Acee, Agree. I think the HOMENET requirements should be derived from major devices in the home network scenario. Maybe currently we should firstly focus on multiple router scenario for traditional fixed and wireless network for multiple services (especially WiFi) , and then introduce LLN network as well for smart objects in the same environment, together with the homenet architecture and new model in the future. Best wishes Qiong I think a viable option for 2012 is that if the LLN networks with their smart objects have to connect to the traditional HOMENET fixed and wireless networks, they will need to do so through a border router supporting both environments. IMHO, we don't need one protocol that meets all requirements for every possible device in the home. Thanks, Acee My first choice would NOT be something that isn't proven in the field in multiple interoperable implementations. As a person thinking about making a recommendation, I'd suggest that folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask themselves why that level of interoperability isn't mandatory. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ rtgwg mailing list rt...@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg ___ manet mailing list ma...@ietf.org https://www.ietf.org/mailman/listinfo/manet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [manet] Question for you
I agree with Jim. The reason why we developed OLSR and the its successor OLSRv2 was precisely that wireless environments are very different from wired. There are plenty of deployments of OLSR and several of OLSRv2, with up to several hundreds of wireless routers, so it is demonstrably working. Regards Ulrich On Mon, Oct 3, 2011 at 12:45 PM, Jim Gettys j...@freedesktop.org wrote: On 10/03/2011 03:32 PM, Tony Li wrote: On Oct 3, 2011, at 12:10 PM, Jim Gettys wrote: My point was just that wireless has a set of challenges that all may not be familiar with; knowing that may help point the discussion in fruitful ways. Routing isn't my area of expertise (though I have scars on my back from it in wireless...). Understood. Yes, wireless has some challenges and I've spent some time in that area. Certainly our standard protocols are not optimal for a purely wireless environment. However, for the generic, heterogenous networks that I would expect in the home, I would expect that the generic protocols would be the better overall approach. Having been seriously scarred by presuming that wireless was similar to wired, I'm a believer in careful testing, rather than expecting that something should work. Without running code, demonstrably working, I'll take nothing on faith in this area. Wireless != wired, is what I took away from that (painful) experience. - Jim Tony ___ manet mailing list ma...@ietf.org https://www.ietf.org/mailman/listinfo/manet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
