Re: [OSPF] A thought about draft-acee-ospf-ospfv3-autoconfig and Human Computer Interaction (HCI)

[Acee Lindem <[e-mail]>]

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 <[e-mail]>
>> To: "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]>
>> 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.
>>