Subject: [homenet] OSPFv3 timers

From: Teco Boot <[email-masked]>
Date: Thu, 8 Nov 2012 05:18:46 +0100

I checked the draft-ietf-ospf-ospfv3-autoconfig-00. I think the proposal doesn't meet expectations of users, with regard of protocol convergence. The default timers are far too conservative. First reconfig on OSPF router in my hands is adjust timers on high speed interfaces to hello=1 and dead=4. This is a bit better than what old days bridges with STP do.
Minor: the timers are not defaults. These are sample values. I have seen routers with different defaults than RFC 5340, for certain interface types.

For autoconfig OSPF, I prefer removal of the restriction that all routers on a link MUST use same timers. That provides flexibility like OLSR. If this is not possible because of reasons for DR selection, I suggest removal of DR completely and configure all interfaces in P2MP. Or MANET interface type, if we want to. Question is: which MANET extension.

[posted here, because requirements come from Homenet]

Teco

---

From: Acee Lindem <[email-masked]>
Date: Thu, 8 Nov 2012 13:03:41 +0000

> I checked the draft-ietf-ospf-ospfv3-autoconfig-00. I think the proposal doesn't meet expectations of users, with regard of protocol convergence. The default timers are far too conservative. First…

This was not considered a requirement in the home. Refer to the section 3.5 in the homenet architecture document. 

> Minor: the timers are not defaults. These are sample values. I have seen routers with different defaults than RFC 5340, for certain interface types.

I'd expect homenet ethernet and WiFi interfaces to default to the broadcast type. 

> For autoconfig OSPF, I prefer removal of the restriction that all routers on a link MUST use same timers. That provides flexibility like OLSR. If this is not possible because of reasons for DR sele…

I'm not sure if there is a real requirement. Routers on the link need to agree on the timer values lest we impact more of the protocol than necessary. Hence, if this is required, the way forward would be for routers on shared links to adopt the timers from their neighbor(s). For simplicity, the same rules used for DR preference could be used. 

Thanks,
Acee

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Teco Boot <[email-masked]>
Date: Thu, 8 Nov 2012 15:24:38 +0100

> This was not considered a requirement in the home. Refer to the section 3.5 in the homenet architecture document. 

Right. Dead=40 does *not* meet the requirement.

See also http://www.ietf.org/mail-archive/web/homenet/current/msg01245.html

Teco

---

From: Acee Lindem <[email-masked]>
Date: Thu, 8 Nov 2012 15:56:24 +0000

I noticed it had been reduced from minutes to 30 seconds in this version. I guess that rules out RIPng.  Since this is a new specification we'll take lower hello/dead under advisement. However, I doubt we go as low as 1 and 4. 
Acee

---

From: Teco Boot <[email-masked]>
Date: Thu, 8 Nov 2012 17:17:55 +0100

> I noticed it had been reduced from minutes to 30 seconds in this version. I guess that rules out RIPng.  Since this is a new specification we'll take lower hello/dead under advisement. However, I d…

Values similar to RSTP would be fine; hello=2, dead=6.
Dead=8 would be more robust, for lost or delayed hello.
Wait doesn't need an adjustment if we go for less slow hellos.

Teco

---

From: Andrew McGregor <[email-masked]>
Date: Thu, 8 Nov 2012 11:28:50 -0500

> Wait doesn't need an adjustment if we go for less slow hellos.

If you end up running this on wireless, remember that wireless multicast tends to be horribly unreliable.  So hello=2 dead=10 is more to the point, that lets you get the false positive dead router rate down quite a bit.

Andrew

---

From: Teco Boot <[email-masked]>
Date: Thu, 8 Nov 2012 17:39:44 +0100

> If you end up running this on wireless, remember that wireless multicast tends to be horribly unreliable.  So hello=2 dead=10 is more to the point, that lets you get the false positive dead router…

Yes.
This brings us to auto-costs and ETX / ETT. 

Teco

---

From: Teco Boot <[email-masked]>
Date: Thu, 8 Nov 2012 20:08:23 +0100

> I'd expect homenet ethernet and WiFi interfaces to default to the broadcast type. 

Then, we cannot have costs per neighbor, correct?
By experience I've became aware this is a bad idea on wireless networks, like WiFi.
What options do we have to fix this?

Teco

---

From: Acee Lindem <[email-masked]>
Date: Thu, 8 Nov 2012 19:26:51 +0000

You'd have to do this through manual configuration. 
Thanks,
Acee

---

From: Teco Boot <[email-masked]>
Date: Fri, 9 Nov 2012 14:49:38 +0100

So this disqualifies OSPFv3 with DR? Support for wireless is 
a main reason to route in the homenet. This brings us to P2MP 
or in the MANET arena.

There is a lot of code out there gathering link metrics for
dynamic links. MANET wg is working on a std track protocol for 
it, called DLEP. This is for transfer of data between radio 
and router devices.

MANET protocols support link metrics quite well now. OLSRv2 is 
near to std track RFC.

Teco

---

From: Acee Lindem <[email-masked]>
Date: Fri, 9 Nov 2012 14:10:12 +0000

Home Wireless Routing != MANET 

Acee

---

From: Teco Boot <[email-masked]>
Date: Fri, 9 Nov 2012 16:05:33 +0100

Yes, it is More Adhoc NETwork and called Homenet. You could be surprised how well MANET protocols work in homenets. This is not my point.

Wireless links need per neighbor link costs, a requirement for the Homenet routing protocol:
   The inclusion of the PHY layer
   characteristics including bandwidth, loss, and latency in path
   computation should be considered for optimising communication in the
   homenet.
Can be done with OSPFv3, so use it. Please suggest how to deal with it.

Teco

---

From: Dave Taht <[email-masked]>
Date: Fri, 9 Nov 2012 16:47:42 +0100

> Can be done with OSPFv3, so use it. Please suggest how to deal with it.

Can be done with olsr, babel, 802.11s, batman, and BMX.

There is a large amount of operational data in the field regarding
doing routing well on wireless networks, and a regular conference
dedicated to exploring how well they actually work in the real world.

http://guifi.net/en/node/17714/view/map

please pack up your favorite ospfv3 and manet extensions and wifi
hardware and go to one.

http://battlemesh.org/

None of the metrics work particularly well, and are functioning badly
in our increasingly bufferbloated universe.

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html