Subject: [homenet] other routing options

From: "Howard, Lee" <[email-masked]>
Date: Tue, 22 Nov 2011 17:36:20 -0500

Ray asked for people to post drafts for anything other than OSPF, because without an alternative, it will appear that we have consensus on OSPF.  I haven't posted a draft on RIPng, because it would just work the way it's designed.

A few people said  http://tools.ietf.org/html/draft-howard-up-pio-00 is no better than RIP, and we already have RIP in home gateways.  Can any gateway vendor confirm whether RIPng is already in gateways?

Proposed alternatives are:
* OSPFv3.  It's heavyweight for home routing.  We still need a way to find the border and inject default.  It could be used for DHCP-PD.
* zOSPF.  It requires resurrecting work.  I don't how much work it needs, or how big the protocol is.
* UP PIO.  It's new work, and requires work.  It's lightweight, and solves the border problem, but not addressing.
* RIPng.  It's fairly lightweight, and it exists.  It solves only the routing problem.
* MANEMO.  It requires resurrecting work, is pretty lightweight, and solves addressing and border problems.

If you argue that we should reuse existing protocols (per the architecture draft), your choices are OSPFv3 or RIPng.  I really don't like OSPFv3 in the home--it's too much protocol, though if someone can tell me about memory footprint, that would be helpful.

I also prefer draft-baker-homenet-prefix-assignment, so we don't need OSPF for addressing.

Any discussion?

Lee

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Randy Turner <[email-masked]>
Date: Tue, 22 Nov 2011 14:49:25 -0800

"OSPF is too much protocol…"

That's how I felt until incredibly elaborate home net topologies were suggested -- but it still seems intuitively heavyweight for a "home" network.  If we do end up using OSPF, then maybe home networks are *not* simple as one would think, but rather a different instantiation of a complex routing scenario, just with "zeroconf" requirements.

R.

On Nov 22, 2011, at 2:36 PM, Howard, Lee wrote:

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

---

From: Fred Baker <[email-masked]>
Date: Tue, 22 Nov 2011 22:41:03 -0800

> Ray asked for people to post drafts for anything other than OSPF, because without an alternative, it will appear that we have consensus on OSPF.  I haven't posted a draft on RIPng, because it would…

Makes sense to me.

> * zOSPF.  It requires resurrecting work.  I don't how much work it needs, or how big the protocol is.

The Internet Draft could be summarized as "Use OSPF, and <do this> for subnet allocation". If you don't like OSPF, you don't like zOSPF.

> * RIPng.  It's fairly lightweight, and it exists.  It solves only the routing problem.

To my way of thinking, as a default protocol for very small networks, you could do worse. I personally prefer OSPF, but I'm a snob :-)

> If you argue that we should reuse existing protocols (per the architecture draft), your choices are OSPFv3 or RIPng.  I really don't like OSPFv3 in the home--it's too much protocol, though if someo…

If you're comparing to RIPng, "a lot more". It's a more complex program, and it not only stores a route table, it stores a link state database. I'd have to go look at something to say this definitively, but I've heard the phrase "order of magnitude" in discussions like these.

---

From: Fred Baker <[email-masked]>
Date: Tue, 22 Nov 2011 22:45:25 -0800

> That's how I felt until incredibly elaborate home net topologies were suggested -- but it still seems intuitively heavyweight for a "home" network.  If we do end up using OSPF, then maybe home netw…

well, halfway in between. If you have a wired LAN and a wireless LAN with two wired/wireless routers, I suspect you have a routing topology with at least one redundant path. I don't care how many nodes you have; if you have a tree, it is "simple" for any protocol. If you have not-all-that-many nodes but have redundancy in the topology, you have the possibility of count-to-infinity problems with a bellman-ford protocol like RIPng. I would suspect that a home network is small compared to, say, a campus in an enterprise network, but if it has redundancy it has at least some probability of the same class of issues.

---

From: Randy Turner <[email-masked]>
Date: Tue, 22 Nov 2011 23:10:29 -0800

So we either bite off much more than we need and get the flexibility of link-state (OSPF), or we add "bounds" to a Bellman-Ford implementation to constrain the count-to-infinity problem, and say that the increased convergence time is ok given that this potential event is unlikely to happen, or that the mean-time between these types of "link-down" events can absorb an increased convergence time.

I do prefer link-state over DV...I'm just trying to look at alternatives :)

We still have the ongoing discussion of how to make all this auto-configurable...

R.

---

From: Randy Turner <[email-masked]>
Date: Tue, 22 Nov 2011 23:29:38 -0800

On the point of autoconfig…in future references to OSPF, can I substitute zOSPF ?  I'm assuming that we're not talking about deploying an off-the-shelf OSPF implementation because of the configuration impact on a home network consumer.  So I was also assuming that I could substitute zOSPF anytime someone mentions OSPF.

R.

---

From: Laurent Toutain <[email-masked]>
Date: Wed, 23 Nov 2011 08:35:44 +0100

On Tue, Nov 22, 2011 at 23:36, Howard, Lee <[email-masked]> wrote:

> Ray asked for people to post drafts for anything other than OSPF, because
> without an alternative, it will appear that we have consensus on OSPF.  I
> haven't posted a draft on RIPng, because it would just work the way it's
> designed.
>
> A few people said  http://tools.ietf.org/html/draft-howard-up-pio-00 is
> no better than RIP, and we already have RIP in home gateways.  Can any
> gateway vendor confirm whether RIPng is already in gateways?
>
> * OSPFv3.  It's heavyweight for home routing.  We still need a way to find
> the border and inject default.  It could be used for DHCP-PD.
>

I don't understand that: a border gateway is a specific device.

> --

Laurent Toutain
+--- VoIP (recommended) ---+----------- Télécom Bretagne -----------+
| Tel: +33 2 22 06 8156    | Tel: + 33 2 99 12 7026                 | Visit
:
| Fax: +33 2 22 06 8445    | Fax: +33 2 99 12 7030                  |
http://class.touta.in
| [email-masked]         | [email-masked]    |
+--------------------------+----------------------------------------+

---

From: Mark Townsley <[email-masked]>
Date: Wed, 23 Nov 2011 08:47:42 +0100

> We still have the ongoing discussion of how to make all this auto-configurable...

Which I think is the more significant piece.... And why we cannot simply accept "just use RIPng" on its own. We have to see what any routing protocol is going to look like with set (by us) defaults and no user configuration, as well as how it either incorporates or interfaces with prefix assignment, border detection, etc. Given the ongoing problems interfacing ND and DHCPv6 we are living through right now with 6204++, I am personally wary to accept that any of these facets in the homenet can truly operate independent from one another. As such, if we have separate protocols and state machines, their interaction needs to be very tightly defined.

- Mark

---

From: Ray Hunter <[email-masked]>
Date: Wed, 23 Nov 2011 09:33:07 +0100

Suspect "border" in this context means "the administrative edge of the 
Homenet domain" and not "OSPF area border router"
Autoconfig has to know when to stop including new devices.

IMHO increasing use of (overlapping) (low power) wireless networks in 
Homenet will only make count to infinity type problems more common, as 
marginal adjacencies come and go. You can solve that within a wireless 
technology, but there's still always going to be the route-over problem 
of overlapping technologies like WiFi versus copper.

What about multicast support for streaming video to my iDevice as I walk 
from the lounge to the pool? AV will likely be a major homenet 
application. OSPF => MOSPF? IPng => DVMRP? Or should that use unicast + 
mobile IPv6?

regards
RayH

Laurent Toutain wrote:
> On Tue, Nov 22, 2011 at 23:36, Howard, Lee <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Ray asked for people to post drafts for anything other than OSPF,
>     because without an alternative, it will appear that we have
>     consensus on OSPF.  I haven't posted a draft on RIPng, because it
>     would just work the way it's designed.
>
>     A few people said
>     http://tools.ietf.org/html/draft-howard-up-pio-00 is no better
>     than RIP, and we already have RIP in home gateways.  Can any
>     * OSPFv3.  It's heavyweight for home routing.  We still need a way
>     to find the border and inject default.  It could be used for DHCP-PD.
>
>
> | Tel: +33 2 22 06 8156    | Tel: + 33 2 99 12 7026                 | 
> Visit :

---

From: Acee Lindem <[email-masked]>
Date: Wed, 23 Nov 2011 06:02:01 -0500

> On the point of autoconfig…in future references to OSPF, can I substitute zOSPF ?  I'm assuming that we're not talking about deploying an off-the-shelf OSPF implementation because of the configurat…

My feeling is that we can continue to call it OSPFv3 with the understanding that OSPFv3 can be optionally auto-configuring. 

Thanks,
Acee

---

From: David Täht <[email-masked]>
Date: Wed, 23 Nov 2011 13:35:17 +0100

>> Ray asked for people to post drafts for anything other than OSPF, because without an alternative, it will appear that we have consensus on OSPF.  I haven't posted a draft on RIPng, because it woul…
I think people should go off and implement *something* in a dual stack 
home routing environment and report back on what happens.

> Makes sense to me.

I have mentioned my fondness for babel earlier in this thread. It's 'RIP 
on speed', and unlike rip doesn't have the counting to infinity 
problem... and does something unique and useful in addition to that, 
supporting mesh routing, which I think is rather important for 
wireless-mostly networks.

Regrettably I do not have time at present to submit a draft on this 
topic, as I'm too busy
actually making code work in cerowrt, fixing bufferbloat, etc. (I'm 
strongly encouraged, btw,
things like the newfangled "byte queue limits" patch and the QFQ queuing 
discipline may actually solve a great deal of the problems we are having 
in this space)

The choice of routing protocol is the least of my problems!

While I'm off on other topics, a version of NAT for ipv6 has been 
submitted to the linux networking mailing list...

Prefix delegation is of interest...

I have wide-dhcpv6 doing pd for example, and I note that the latest 
release candidate of dibbler looks pretty good as active development 
resumed about a year ago. As for how well that can integrate with 
anything else, is kind of unknown.

Does anyone actually have a home router running ospf over ipv6?

a couple more comments below. I'd like to make clear that I'm neutral - 
merely that ospf didn't do what I wanted when last I tried it.

olsr and batman do - except that the former requires two daemons at 
present to run and is weird on ipv6, and batman doesn't do ipv6, which 
reduces my own choices to... no, I'm not going to say it...

>> A few people said  http://tools.ietf.org/html/draft-howard-up-pio-00 is no better than RIP, and we already have RIP in home gateways.  Can any gateway vendor confirm whether RIPng is already in ga…

RIP is not available for v6 in any home gateway I'm aware of. I could be 
out of date on that.
>> * OSPFv3.  It's heavyweight for home routing.  We still need a way to find the border and inject default.  It could be used for DHCP-PD.
it's a one liner for babel to pick up a default gateway injected by dhcp 
or dhcpv6.

> The Internet Draft could be summarized as "Use OSPF, and<do this>  for subnet allocation". If you don't like OSPF, you don't like zOSPF.
>

And me, AHCP + babel...

>> If you argue that we should reuse existing protocols (per the architecture draft), your choices are OSPFv3 or RIPng.  I really don't like OSPFv3 in the home--it's too much protocol, though if some…

  An ipv6 capable home router needs a minimum of 32MB of ram and 16 MB 
of flash, at present. Inside of that are many other daemons that eat up 
over half that ram, and the rest is used for buffering.

It will be nearly impossible to find one that has less than 64MB in the 
fairly near future.

Home routers do not swap. However, when under memory pressure they can 
generally drop read only pages with high effectiveness...

You can dismember any of hundreds of home routers and see the various 
components in action. there are daemons for dhcp, dhcp serving, ntp, 
dns, ra announcements, and a web server, at minimum.

Any set of "inside the home" internal routing tables is likely to be so 
much smaller than the other required features in the device as to be not 
worth thinking about much.

Unless people are seriously considering running BGP on the home router...

... I can't think of any other modern protocol that will eat up more 
memory than (for example) the web server, or wireless management daemon, 
at least, not until we get around to routing thousands of in-home 
movement sensors, or something like that.

This assumption would require testing, of course. Particularly the sensors.

-- 
Dave Täht

---

From: "Howard, Lee" <[email-masked]>
Date: Wed, 23 Nov 2011 12:21:52 -0500

> IMHO increasing use of (overlapping) (low power) wireless networks in Homenet will only make
> count to infinity type problems more common, as marginal adjacencies come and go.

You mean 6lowpan type networks?  I thought we had consensus to draw a circle around them and
say, "put a device between that network and this."

> What about multicast support for streaming video to my iDevice as I walk from the lounge to
> the pool? AV will likely be a major homenet application. OSPF => MOSPF? IPng => DVMRP?
> Or should that use unicast + mobile IPv6?

Streaming video != multicast.  I don't think we've had any discussion of multicast, except in
the context of mDNS.  I don't need it in the home.  Do you?

Lee

---

From: Ray Bellis <[email-masked]>
Date: Wed, 23 Nov 2011 17:24:08 +0000

On 23 Nov 2011, at 17:21, Howard, Lee wrote:

> You mean 6lowpan type networks?  I thought we had consensus to draw a circle around them and say, "put a device between that network and this."

That was certainly the room consensus at the Interim and will hopefully be reflected in the architecture draft.

Ray

---

From: Randy Turner <[email-masked]>
Date: Wed, 23 Nov 2011 09:52:40 -0800

Apple, Sony, Samsung, et.al., will use DLNA and other types of mechanisms that rely on multicast for service (content) discovery on the home network. Once the streams actually "start", they are currently unicast, but even this will change very soon.

Randy

---

From: Ray Hunter <[email-masked]>
Date: Wed, 23 Nov 2011 19:06:00 +0100

> say, "put a device between that network and this."
I agree on 6LoWPAN: it has a clear gateway router, it's own routing 
protocol, and should not be expected to provide an inter-Homenet link.

But you can still have various flavors of WiFi that could be acting as a 
(marginal) inter-router link, in parallel with copper.
What about those? Are they also stub networks that only service end 
nodes? How do you know? How do you avoid 2 routers forming an OSPF/RIPng 
adjacency if it's a single SSID just within wireless range of each 
other? That might be exactly what you want in some cases.
> the context of mDNS.  I don't need it in the home.  Do you?
That was exactly my question. As a consumer I'd like video distributed 
around my home available to mobile devices: I don't really care how it's 
transported. The video may well arrive into the home via multicast over 
cable via DOCSIS. The set top box is in the living room but my TV is in 
the bedroom. Do we expect people to run the cable TV network to every 
room to separate set top boxes with their own decryption cards and keep 
this outside of Homenet? Do we expect AV manufacturers to always unicast 
video within the Homenet? e.g. if I want my camera with my own copyright 
content to play on a remote system? Or should we discuss whether the 
choice of unicast routing protocol has a knock on effect to multicast 
routing?

I'd like to keep things simple too, but I think it's an important 
scoping question to get clear consensus on.

regards,
RayH

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 24 Nov 2011 08:31:29 +0100

6LoWPAN is not that specific and if every home usage needs a special
gateway, we're designing against the end to end principle.

Take the stereo / home theater. This is prone to become an ad hoc
network where infrared and cable connections will be replaced by various
flavors of 802.15, e.g. Bluetooth for RCA replacement, Zigbee for
infrared, and UWB for HDMI. 

RPL is designed to accommodate that. It can build multiple constrained
routing topologies within a same subnet. For instance one topology can
be rooted at the screen, and dedicated to video by constraining the
links to UWB.  

And a recent draft allows cascading topologies.

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ray Hunter
Sent: mercredi 23 novembre 2011 19:06
To: Howard, Lee
Cc: Laurent Toutain; [email-masked]
Subject: Re: [homenet] other routing options

		> IMHO increasing use of (overlapping) (low power)
wireless networks in Homenet will only make
		> count to infinity type problems more common, as
marginal adjacencies come and go.

	You mean 6lowpan type networks?  I thought we had consensus to
draw a circle around them and
	say, "put a device between that network and this."

	> Or should that use unicast + mobile IPv6?

Streaming video != multicast.  I don't think we've had any discussion of
multicast, except in
the context of mDNS.  I don't need it in the home.  Do you?

regards,
RayH

---

From: Ray Bellis <[email-masked]>
Date: Thu, 24 Nov 2011 08:13:58 +0000

On 24 Nov 2011, at 07:31, Pascal Thubert (pthubert) wrote:

RPL is designed to accommodate that.

Please see our message of 17th November.

If your favourite routing protocol is not being considered, please write a draft describing its applicability to Homenet.

thanks,

Ray

---

From: Teco Boot <[email-masked]>
Date: Fri, 25 Nov 2011 08:47:51 +0100

> If your favourite routing protocol is not being considered, please write a draft describing its applicability to Homenet.

IS-IS is not my favorite. Also, I know almost nothing about TRILL. But I think these should be considered. Don't expect a draft from me.

Teco

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Nov 2011 08:12:21 +1300

On 2011-11-25 20:47, Teco Boot wrote:
...
> IS-IS is not my favorite. Also, I know almost nothing about TRILL. But I think these should be considered. Don't expect a draft from me.

TRILL is not an IP routing protocol. It's a layer 2 bridging protocol more
complicated than the spanning tree, and seems completely unnecessary for
the small size of bridged networks to be expected in homenets.

   Brian

---

From: Joel jaeggli <[email-masked]>
Date: Fri, 25 Nov 2011 11:59:47 -0800

> choice of unicast routing protocol has a knock on effect to multicast

multicast as frequently deployed on wireless networks tends to be
terribly expensive, e.g. if it's transmitted at the lowest available rate.

within the home, at least with fairly high rate wireless devices you'll
probably find it more scalable to unicast it.

---

From: Russ White <[email-masked]>
Date: Fri, 25 Nov 2011 21:17:38 -0500

> the small size of bridged networks to be expected in homenets.

What might actually be ideal is something that can route both at layer 2
and at layer 3 --I.e., that can treat layer 2 and layer 3 within the
home identically...

:-)

Russ

---

From: Teco Boot <[email-masked]>
Date: Sat, 26 Nov 2011 12:58:45 +0100

> and at layer 3 --I.e., that can treat layer 2 and layer 3 within the

Yes, route VLANs. It makes sense to bind equivalent L2 links to a single L3 
link. Dummies are faced the fact that broadcasts on home link and guest link
simply works. No need for new protocols, L3 multicast and app upgrades.

As long as dual stack is in use, dummies don't understand different 
topologies for the stacks. They should not be aware of dual stack in the 
first place.

Teco

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Sun, 27 Nov 2011 22:49:55 +0100

> and at layer 3 --I.e., that can treat layer 2 and layer 3 within the

We have a saying in Spanish about "killing flies with cannonballs", and probably what I suggest here will be, but I have been the whole week reading and discussing about Seamless MPLS, and it sounded precisely like you said...

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:      +34 913 129 041
-----------------------------------------

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 27 Nov 2011 16:24:49 -0800

On 11/27/11 13:49 , DIEGO LOPEZ GARCIA wrote:
>>> TRILL is not an IP routing protocol. It's a layer 2 bridging
>>> protocol more complicated than the spanning tree, and seems
>>> completely unnecessary for the small size of bridged networks to
>>> be expected in homenets.
>> 
>> What might actually be ideal is something that can route both at
>> layer 2 and at layer 3 --I.e., that can treat layer 2 and layer 3
>> within the home identically...
> 
> 
> We have a saying in Spanish about "killing flies with cannonballs",
> and probably what I suggest here will be, but I have been the whole
> week reading and discussing about Seamless MPLS, and it sounded
> precisely like you said...

Having routing protocols that are in-fact agnostic about what AF they
are carrying as in the past proved useful when it was found necessary to
carry another one.

> 
> -- "Esta vez no fallaremos, Doctor Infierno"
> 
> Dr Diego R. Lopez Telefonica I+D
> 
> e-mail: [email-masked] Tel:      +34 913 129 041 
> Este mensaje se dirige exclusivamente a su destinatario. Puede
> consultar nuestra política de envío y recepción de correo electrónico
> en el enlace situado más abajo. This message is intended exclusively
> for its addressee. We only send and receive email on the basis of the
> terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx 
> _______________________________________________ homenet mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Randy Turner <[email-masked]>
Date: Sun, 27 Nov 2011 19:50:33 -0800

Should we be looking at what the IEEE p1905.1 group is doing…their PAR reads like there may be some synergy between what we have been discussing and their scope of work.  

Apologies if this has come up before…

Randy

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Nov 2011 10:35:29 +1300

> and at layer 3 --I.e., that can treat layer 2 and layer 3 within the

I have no doubt that if you convinced Radia about this, she could suggest
an IS-IS-TRILL variant that would achieve it.

But I'm not sure I really understand the need for it. There's no shortage
of IPv4 address space in homenets, because they are small and in RFC 1918
space. So if you are routing IPv6 in a home net, why not also route IPv4?

   Brian

---

From: Russ White <[email-masked]>
Date: Tue, 29 Nov 2011 16:52:17 -0500

> space. So if you are routing IPv6 in a home net, why not also route IPv4?

My point is that just as we have applications that want layer 2
connectivity between data centers today, I can easily imagine such
applications within a home... So why not plan for a single control plane
that can route _anything_ from the very beginning.

TRILL is way overkill for this application --go back to the original,
simple idea of just placing layer 2 addresses in a different AF in an
existing and proven routing protocol, like OSPFv3. Use some MANET
extensions to make it scale at the control plane level, and use AF's to
provide routing of anything to anything within the local domain. Assume
you won't have flooding domain boundaries, etc., and no interaction with
spanning tree, either.

In other words --we often think about routing a particular "thing." For
homenet, it makes more sense to provide a generic control plane, and
then figure out how to provide reachability for anything you can throw
at it. IPv4? Shouldn't be an issue. IPv6? Same thing. Ethernet? A new AF
and you're done. Bluetooth extension over the network? I don't see why
it should matter --one control plane, all applications.

Russ

---

From: Shane Amante <[email-masked]>
Date: Tue, 29 Nov 2011 18:55:00 -0700

> it should matter --one control plane, all applications.

+1

-shane

---

From: Teco Boot <[email-masked]>
Date: Wed, 30 Nov 2011 08:55:55 +0100

Let's not classify protocols yet. Maybe IS-IS-TRILL is overkill and
OSPFv3-&AF-&MANETextensions-&L2extensions is not. Or otherwise.

The main point is: we have to deal with v4, v6 and VLANs. Dual stack 
guest network may have multiple L2 links, connected via some kind of 
backbone link (e.g. powerline), and hooked up to a firewall somewhere.

Teco