Hi Mark, Sorry for the delay and taking this discussion to the list. I'm hesitant to create a new P2MP interface variation and make it the default auto-configured type when the broadcast interface is the most common. I am very familiar with scenario you are attempting to handle is the case where neither router port is up until you connect them since your topology is back-to-back rather than thru a switched infra-structure. Hence, you are always subject to the WAIT time prior to prior DR election. My answer would be to add a section covering this case and reducing the WAIT time to a smaller number. I'd recommend 15 seconds but allow for implementations to go lower if they believed their market demanded it (at the expense of a higher likelyhood of DR recalculation). Thanks, Acee
On Sep 27, 2012, at 5:38 AM, Mark ZZZ Smith wrote: > Hi, > > A clarification. The form of point-to-multipoint operation I am suggesting is > where multicast hellos are used to discover neighbors rather than having to > configure them. Cisco routers have this capability, and I'd assumed that the > OSPF RFCs allowed for this combination of neighbor discovery and then > neighbor adjacency establishment. However, I've looked at the OSPF RFCs > today, and they don't seem to specifically mention it, although don't seem to > preclude it either. > > Regards, > Mark. > > > ----- Original Message ----- >> From: Mark ZZZ Smith <[email protected]> >> To: "[email protected]" <[email protected]>; >> "[email protected]" <[email protected]> >> Cc: >> Sent: Thursday, 27 September 2012 6:30 AM >> Subject: A thought about draft-acee-ospf-ospfv3-autoconfig and Human >> Computer Interaction (HCI) >> >> Hi, >> >> I think OSPF is a good protocol for use as a routing protocol in a home >> environment, in particular as I think it could also be used as a service >> distribution protocol (e.g. printer names etc.), similar to how Novell used >> their IPX version of IS-IS (NLSP). >> >> However, I think it would be better to use point-to-multipoint mode on the >> interfaces rather than traditional DR/BDR mode. The reason is because of >> Human >> Computer Interaction concerns. I'm not an expert in HCI, however I am aware >> that humans will only tolerate apparent inactivity for no more than 3 to 5 >> seconds, before they decided that nothing is or has happened and start >> taking >> actions to attempt to fix it (with the common action with low end CPE being >> to >> reboot it). To address this, a device or piece of software either has to >> indicate progress of some form (e.g. move a percent complete bar), or >> complete >> the task within 3 to 5 seconds. >> >> Using the DR/BDR interface mode, and leaving the timers as defaults, end >> users >> of CPE are going to have to wait for up to 40 seconds before OSPF has >> completed >> establishing an adjacency. This will be far to long unless the CPE indicates >> progress such as flashing a progress LED periodically. Even then I think >> such a >> long delay doesn't really provide much value. >> >> I think it would be better to use a point-to-multipoint interface mode for >> OSPF, >> avoiding a DR/BDR elections, and to set the hello interval to something like >> 2 >> seconds, and perhaps a dead interval 6 seconds. Although this would mean >> OSPF >> routes would maintain a full mesh of adjacencies with each other on the same >> segment, there are unlikely to be enough that it causes any load issue on >> CPE as >> CPE has much more powerful CPUs and much more RAM than routers did when OSPF >> was >> developed. >> >> (I remember there was a recommendation from Cisco in the early 1990s to have >> no >> more than 50 routers and 200 links in an OSPF area, and that was with Cisco >> 2500s, using a 20 Mhz Motorola 68020 CPU and having 512 KB of RAM. CPUs in >> CPE >> these days are at least 200 and more likely 400Mhz, and have 16 to 32 MB of >> RAM. >> They should have no trouble maintaining a full mesh of OSPF adjacencies >> between >> quite a large number of OSPF neighbors on a link. For >> example, http://wiki.openwrt.org/toh/tp-link/tl-mr3020, which costs around >> US$50.) >> >> HTH, >> Mark. >>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
