Subject: Re: [homenet] Clarification on Routing Thoughts

From: Ole Troan <[email-masked]>
Date: Fri, 1 Aug 2014 12:44:34 +0200

>>> It seems to me that you are grasping for a use case to justify a split
>>> where none is needed.  Protocols like OSPF, IS-IS and Babel would all
>>> work in both environments. RIP won't.  So this seems more like an
>>> argument not to use RIP than an argument to have two different homenet
>>> router profiles.
>> 
>> For the record, can you expound on the technical reason why RIP(v2) won't
>> work?  (I'm not a fan of it, but last time I used it was on SunOS 3 or
>> something)
> 
> hop count isn't a great tool for expressing that  your gig-e port is a
> more desireable path if up  then the wifi interface.
> 

the cost/metric is perfectly fine for that.
assuming a relatively small network diameter.

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 01 Aug 2014 13:28:00 +0200

> assuming a relatively small network diameter.

I think Joël's reluctance about hopcount qualifying the gig-e/wifi
choice may change if considering wifi-ac instead. I.e. hopcount may be
good to qualify a choice between Gigabit Ethernet and Gigabit wifi.

Alex

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

---

From: Henning Rogge <[email-masked]>
Date: Fri, 1 Aug 2014 13:32:39 +0200

> good to qualify a choice between Gigabit Ethernet and Gigabit wifi.

Measuring any kind of wifi connection just with "hopcount" is not a
good idea. Even 802.11ac will downgrade to a few Mbit/s if the
connection is bad.

Henning Rogge

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 1 Aug 2014 13:12:53 +0000

On 8/1/14, 2:10 AM, "Markus Stenberg" <[email-masked]> wrote:

>On 1.8.2014, at 4.03, Michael Richardson <[email-masked]> wrote:
>> Ted Lemon <[email-masked]> wrote:
>RIPng (RFC2080) isn¹t source specific, I¹m not sure if there¹s something
>more recent on RIP front that is (and is widely implemented available).
>Obviously, extending RIPng to be source specific would not be hard, but
>then it wouldn¹t be RIP anymore by strict definition (no existing
>implementations).

Given the current RIPng standard timers, it could also be argued that
RIPng, as specified, doesn¹t meet the convergence requirements. Here is an
excerpt from section 3.5.1 of "IPv6 Home Networking Architecture
Principles²: 

   Minimising convergence time should be a goal in any routed
   environment.  It is reasonable to assume that convergence time should
   not be significantly longer than network outages users are accustomed
   to should their CER reboot.

There is the imperfect solutions to the ³counting to infinity² problem in
Ring. 

Thanks,
Acee 

>Cheers,
>-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 01 Aug 2014 18:47:15 +0200

> RIPng, as specified, doesn't meet the convergence requirements.

>    to should their CER reboot.

Detecting a dead router in the absence of an explicit retraction takes one
minute, worst case, 45 seconds average.  After that, convergence happens
in 30 seconds, worst case, if you're using triggered updates.  Assuming
you're also doing split horizon, typical convergence times are on the
order of 4 seconds in many reasonable topologies.  (Note that Quagga's
RIPng doesn't implement triggered updates, please don't use it for
testing.)

So we're speaking of 90 seconds worst case -- including the time needed
for virtual link sensing --, and roughly 55 seconds average convergence
times, with the default timers.  (Note that the biggest part of this
figure is due to the slow virtual link sensing -- counting to infinity is
not the main flaw of RIPng, contrary to common perception.)

That's abysmally slow when compared with OSPF, but way less than the time
needed for an ADSL modem to reboot and establish ADSL sync.  I'm not sure
we should be promoting RIPng at this stage, Acee, but neither should we
disqualify it outright.  If somebody comes out with strong arguments in
favour of RIPng, we should be keeping an open mind.

-- Juliusz (who is looking forward to implementing the source-sensitive
            extensions to RIPng)

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 1 Aug 2014 17:35:23 +0000

>favour of RIPng, we should be keeping an open mind.

I¹m fine as long as the consensus of the WG is that it meets the
requirements. 

Thanks,
Acee

---

From: joel jaeggli <[email-masked]>
Date: Sat, 02 Aug 2014 12:59:46 -0700

> good idea. Even 802.11ac will downgrade to a few Mbit/s if the

The more germain point is if there are heterogeneous link layers
available in a routed topology some signaling to indicate which is a the
most desirable path (cost) is on order. just because two device are
connected via the zigbee network doesn't mean they should use it as a
communications path if they are also connected via wifi or ethernet.