Subject: [homenet] Clarification on Routing Thoughts

From: RJ Atkinson <[email-masked]>
Date: Fri, 25 Jul 2014 12:10:55 -0400

I apologise that I did not organise my thoughts well earlier, 
so I will try to complete -- hopefully in a more clear way 
-- the thoughts I was trying to express earlier in the WG mtg.

TERMINOLOGY;
  Anyplace I say "home" or "residence" below, I also
  mean to include "small business" or any other smallish
  organisation that might have a HomeNet type deployment.

OBSERVATION:
  The HomeNet WG has at least 2 distinct communities
  in its membership, with at least 2 sets of objectives.

  There might well be more than 2, but hallway discussions
  this week make it clear to me that we have at least 2.
  So I think it unlikely that the WG can converge on
  any single solution for unicast routing.  

  I doubt it is worth a lot of effort to try to force 
  a single solution.  I am not even sure it is necessary.

USER COMMUNITIES:
  The WG has at least 2, possibly more, communities
  within its membership.  These have at least some
  divergence in their goals/objectives, although there
  are some areas of commonality.

A) Service Providers

  Several service providers want a Homet Net solution
that lets them manage/provide/trouble-shoot the home
networks inside their residential customers' homes and
apartments.  Service providers are comfortable with
link-state routing and probably prefer IS-IS over OSPF
for cultural reasons.  Their goal is to reduce their
operating expenses by reducing/eliminating telephone
calls from users.  

  So they will prefer a link-state approach to unicast 
routing within the home (or small business).  This community 
is quite happy to adopt DHCP options and other IETF technology.  
In many cases, but not all cases, the equipment budgets 
are less critical than the potential for operating cost 
reductions (because operating costs recur, while capital
costs are periodic).  Something like HNCP has a good chance 
of also being included in their solutions.

B) Consumer Electronics Vendors

  Many home users want to purchase their own in-home
networking equipment and do NOT want to use provider-
supplied equipment.  The same is true for many small
businesses.  Consumer electronics vendors already
are quite happy supplying this market.  Consumer electronics
vendors operate with thinner margins (e.g. eliminating one
resistor makes a meaningful difference in their profit).
Memory footprint and CPU cost matter a great deal to these
manufacturers.  They already have RIP, RIP is nearly zeroconf,
and adding a link-state routing protocol would increase
both their manufacturing cost and their support cost.
Moreover, RIP scales just fine for residential and even
small-business networks.  It is nearly zeroconf, which
is a bonus.  

  So these folks are not likely to add any link-state
routing protocol to their products.  They are likely 
to add a few DHCP(v6) options that are useful and also 
are likely to add at least parts of HNCP (maybe the whole
of HNCP if the footprint/complexity is small/low enough).

PERSPECTIVE:

  It would optimise WG productivity to focus on matters
  other than trying to select a single unicast routing protocol.

  We can focus on making HNCP as good as it can be, identifying 
  relevant DHCP(v6) options (possibly new options), identifying
  outputs from the IETF DNS-SD work that are applicable 
  (and citing them as appropriate), and sorting out the other
  non-unicast-routing parts of the Home Net problem space.

Yours,

Ran

PS:  I agree with whomever spoke up earlier today about the
     importance of supporting IP multicasting throughout a
     HomeNet deployment.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 25 Jul 2014 12:52:54 -0400

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.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 25 Jul 2014 21:31:30 +0200

RJ,

If I understand you right, you're pushing for an approach where we don't
say anything about the routing protocol, and wait for the market to
converge on RIPng, thus ensuring interoperability.  Please correct me if
I've misunderstood you.

(My personal opinion right now (subject to change) is that we want
a single Homenet protocol, but ensure that HNCP is designed so it is
protocol-agnostic.  We should make it clear that, while we encourage
experimentation with other routing protocols, deploying HNCP with
a non-Homenet routing protocol is not Homenet-compliant and doesn't give
you the right to put the cool Homenet logo on your router.)

> Consumer electronics vendors operate with thinner margins
> (e.g. eliminating one resistor makes a meaningful difference in their
> profit).  Memory footprint and CPU cost matter a great deal to these
> manufacturers.

I think you're underestimating the amount of RAM and CPU in current cheap
routers.  The three cheapest routers I can find on Wallmart's website have
between 16 and 32MB of RAM and a 300MHz MIPS CPU.  That's plenty for
running RIPng and Babel, and probably more than enough for a single-area
variant of OSPF or IS-IS (Acee, can you confirm?).  (The only reason I can
see why these routers are unsuitable for Homenet is lack of flash -- some
have as little as 4MB.)

(Note that these are too slow to push anything close to 100Mb/s, even
without firewalling, which, I suspect, is the reason why recent designs
have switched to faster CPUs.)

> They already have RIP,

Do they?  Are there any cheap routers that come with RIP enabled by default?

> RIP is nearly zeroconf, and adding a link-state routing protocol would
> increase both their manufacturing cost and their support cost.
> Moreover, RIP scales just fine for residential and even small-business
> networks.

Just like you, I really like RIP, and could certainly live with RIPng
being the One Homenet Routing Protocol.  However, RIP(ng) has three major
flaws:

 - the metric is a 4-bit integer, which seriously limits your ability to
   do fun stuff (like forcing traffic to follow the nice 1Gb/s cabling in
   preference to the unstable wifi);
 - the lack of explicit hello packets slows down link detection -- and
   there's no way you'll do a cool demo unless you can unplug the ethernet
   jack and have the traffic rerouted within seconds (with RIP, you'll
   need on the order of a minute, unless you have link-layer indications,
   which don't work well for other reasons);
 - RIP is unable to detect unidirectional failures.

I don't see the lack of source-specific routing as a serious flaw, since
desigining and implementing a source-specific extension to RIPng is
probably a job for a day or two (I'm assuming you allow me to copy-paste
from Babel and keep me furnished in coffee and food).

> So these folks are not likely to add any link-state routing protocol to
> their products.

While I share your distaste for the "link-state everywhere" dogma, those
folks who base their firmware on OpenWRT will add whatever doesn't require
configuration and is well supported by OpenWRT.  Those who don't are going
to swear at us anyway.  (Think of it as a consulting opportunity.)

-- Juliusz

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 25 Jul 2014 18:04:22 -0400

On 25  Jul 2014, at 15:31 , Juliusz Chroboczek wrote:
> If I understand you right, you're pushing for an approach where 

Not correct.  I'm not "pushing" for anything.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 25 Jul 2014 18:09:33 -0400

On 25  Jul 2014, at 12:52 , Ted Lemon wrote:
> So this seems more like an argument ...

Ted,

To be clear, since you seem confused, my comments 
were not an argument for or against anything,
just a set of observations.

Cheers,

Ran

---

From: Ted Lemon <[email-masked]>
Date: Sat, 26 Jul 2014 01:27:05 -0400

> just a set of observations.

I don't mean that you intended to argue that way.   It's just the conclusion I drew from the statements you made.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 26 Jul 2014 10:43:03 +0000

On 7/25/14, 3:31 PM, "Juliusz Chroboczek" <[email-masked]>
wrote:

>variant of OSPF or IS-IS (Acee, can you confirm?).

Yes - it should be more than enough. Recall that Markus¹ OSPFv3 Bird
implementation report presented Berlin.

http://www.ietf.org/proceedings/87/slides/slides-87-homenet-2.pdf

I¹d expect ISIS to be similar since commercial SP implementation sizes are
comparable. 

Thanks,
Acee 

>(The only reason I can
>_______________________________________________
>homenet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/homenet

---

From: Brian Haberman <[email-masked]>
Date: Sat, 26 Jul 2014 11:30:07 -0400

> you the right to put the cool Homenet logo on your router.)

To quote an IESG colleague:

"The IETF does not do compliance."

The goal should be increasing the probability of interoperability
between devices from different vendors.

Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 27 Jul 2014 07:42:35 +1200

On 27/07/2014 03:30, Brian Haberman wrote:
...
> between devices from different vendors.

Exactly, which traditionally means a single mandatory-to-implement
protocol, even if it's the Tossacoin protocol. Whether vendors
take any notice is outside our control.

<humour>Tossacoin, i.e. random routing, is of course a valid routing
algorithm in itself. Isn't that the original reason why we had a
TTL/hop count? It would probably work quite well in a small
homenet. </humour>

    Brian C

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 27 Jul 2014 01:42:22 +0200

> Tossacoin, i.e. random routing, is of course a valid routing algorithm
> in itself. Isn't that the original reason why we had a TTL/hop count? It
> would probably work quite well in a small homenet.

I call it hot potato routing, and I define it as choosing a random
interface other than the one through which the packet was received.
I once brought some actual potatoes to my lecture, and we implemented hot
potato routing; it turned out being a good introduction to the subject of
packet drops.  (I don't think we ever laughed so much during one of my
lectures.)

Next time, I'll do mashed potato routing.

-- Juliusz

---

From: Michael Thomas <[email-masked]>
Date: Sat, 26 Jul 2014 17:51:51 -0700

> packet drops.  (I don't think we ever laughed so much during one of my

I wonder if anybody has ever considered routing from a natural selection
perspective. You throw random mutations (router chaos monkeys!) into the
routing tables every once in a while and see if the packet progeny dies off
or becomes more fit. Perhaps the mutation rate is the result of feedback
from the packet mortality rate, and backhoes are the equivalent of 
asteroids,
cf punctuated evolution.

(maybe we can borrow some v6 address bits for the genetic material? :)

Mike

---

From: Michael Richardson <[email-masked]>
Date: Fri, 01 Aug 2014 00:03:34 -0400

Ted Lemon <[email-masked]> wrote:
    > 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)

-- 
Michael Richardson
-on the road-

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 1 Aug 2014 06:10:26 +0000

> work?  (I'm not a fan of it, but last time I used it was on SunOS 3 or

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).

Cheers,

-Markus

---

From: joel jaeggli <[email-masked]>
Date: Thu, 31 Jul 2014 23:18:05 -0700

> work?  (I'm not a fan of it, but last time I used it was on SunOS 3 or

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.