Re: [homenet] other routing options

[Lorenzo Colitti]

On Thu, Dec 1, 2011 at 13:38, Jim Gettys  wrote:

> > Because the primitives that are available to you in IPv4 (essentially,
> > NAT and DHCPv4) are different to the primitives available to you in
> > IPv6. IPv6 allows you to do stuff like deprecate your default gateway
> > and prefix, and to have multiple default gateways. IPv4 does not. So I
> > suspect that when you look at things, you're not going to be able to
> > route IPv4 reliably.
> >
> This mail serves as "running code" counter example.  CeroWrt routes
> IPv4 today, and I've been happy for months.
>

Sure, it will work in static topologies. It won't work so well when you
move stuff around. Bridging, or IPv6 routing, does.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Jim Gettys]

On 12/01/2011 03:27 PM, Lorenzo Colitti wrote:
> On Mon, Nov 28, 2011 at 13:35, Brian E Carpenter
> mailto:brian.e.carpen...@gmail.com>> wrote:
>
> 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?
>
>
> Because the primitives that are available to you in IPv4 (essentially,
> NAT and DHCPv4) are different to the primitives available to you in
> IPv6. IPv6 allows you to do stuff like deprecate your default gateway
> and prefix, and to have multiple default gateways. IPv4 does not. So I
> suspect that when you look at things, you're not going to be able to
> route IPv4 reliably.
>
This mail serves as "running code" counter example.  CeroWrt routes IPv4
today, and I've been happy for months.

The questions around routing versus bridging are completely different
than that alleged: the issue is whether you can discover the services
you may need that are present on other networks on the home, e.g.
available via MDNS, or SMB, etc. There are implicit assumptions that
various gear has that everything may be in the same broadcast domain,
and that is exactly what we're trying to avoid by routing everything (as
wireless broadcast is an offence against humanity).  So we're still
shaking down problems that surface (e.g. by using mdnsresponder, and
seeing if we can get a wins server properly configured and the like. 
Whether there are any show-stoppers lurking, I do not yet know.

Since CeroWrt traffic was cluttering up the more general discussions on
bufferbloat, we just split those off. If you are interested, join the
mailing lists on CeroWrt.  See the attached mail.

Fundamentally, I personally believe anything this working group does
should be tested in running code before going anywhere in the standards
process.  Without running code, consensus will be hard to achieve.
Best regards,
Jim Gettys

--- Begin Message ---
I have created cerowrt-users, cerowrt-devel, and cerowrt-commits

mailing lists  on http://lists.bufferbloat.net

Please subscribe to one or more of those if the cerowrt test router subproject
 is your interest. I note also you can submit bug reports and comments directly
into the 'cerowrt' user on lists.bufferbloat.net and they will
automagically enter
the bug system there.

For now I plan to keep using the #bufferbloat channel for cerowrt support
unless that gets out of hand too.

I will periodically point out news of import regarding cerowrt and as relating
to bufferbloat to multiple lists here, but let's keep stuff that
mostly cerowrt and
not bloat related over there, ok?

If anyone has any other suggestions for useful lists to create, now is
the time to ask.

One of my thoughts was to resurrect the old lartc list, which
discussed user issues with
traffic shaping and control in particular. It was useful in it's
heyday and there seems
to be some market for the idea re-occurring.

There has been some talk of doing that
instead over on vger.kernel.org, and I'm cool with that, if it happens.

comments?

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
___
Bloat-devel mailing list
bloat-de...@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat-devel
--- End Message ---
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Lorenzo Colitti]

On Mon, Nov 28, 2011 at 13:35, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:

> 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?


Because the primitives that are available to you in IPv4 (essentially, NAT
and DHCPv4) are different to the primitives available to you in IPv6. IPv6
allows you to do stuff like deprecate your default gateway and prefix, and
to have multiple default gateways. IPv4 does not. So I suspect that when
you look at things, you're not going to be able to route IPv4 reliably.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Teco Boot]

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


Op 29 nov. 2011, om 22:52 heeft Russ White het volgende geschreven:

> 
>> 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?
> 
> 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
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Shane Amante]

On Nov 29, 2011, at 2:52 PM, Russ White wrote:
>> 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?
> 
> 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.

+1

-shane
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Russ White]

> 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?

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Brian E Carpenter]

On 2011-11-26 15:17, Russ White 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...

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Randy Turner]

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Joel jaeggli]

On 11/27/11 13:49 , DIEGO LOPEZ GARCIA wrote:
> 
> On 26 Nov 2011, at 03:17 , Russ White 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: di...@tid.es 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 
> homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[DIEGO LOPEZ GARCIA]

On 26 Nov 2011, at 03:17 , Russ White 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...


--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

e-mail: di...@tid.es
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
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Teco Boot]

Op 26 nov. 2011, om 03:17 heeft Russ White het volgende geschreven:

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

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 

> 
> :-)
> 
> Russ
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Russ White]

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

:-)

Russ
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Joel jaeggli]

On 11/23/11 10:06 , Ray Hunter wrote:
>>> > 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."
>>
>>   
> 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.
>>> > 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?
>>   
> 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?

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.

> I'd like to keep things simple too, but I think it's an important
> scoping question to get clear consensus on.
> 
> regards,
> RayH
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Brian E Carpenter]

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Teco Boot]

Op 24 nov. 2011, om 09:13 heeft Ray Bellis het volgende geschreven:

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

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


> 
> thanks,
> 
> Ray
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Ray Bellis]

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Pascal Thubert (pthubert)]

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: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On
Behalf Of Ray Hunter
Sent: mercredi 23 novembre 2011 19:06
To: Howard, Lee
Cc: Laurent Toutain; homenet@ietf.org
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."
 
  

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.



> 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?
  

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Ray Hunter]

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

   
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.

>  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?
   
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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Randy Turner]

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

On Nov 23, 2011, at 9:21 AM, Howard, Lee wrote:

>> 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
> 
> 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.
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Ray Bellis]

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


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Howard, Lee]

> 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

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.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[David Täht]

On 11/23/2011 07:41 AM, Fred Baker wrote:

On Nov 22, 2011, at 2:36 PM, Howard, Lee 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.
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 gateways?


RIP is not available for v6 in any home gateway I'm aware of. I could be 
out of date on that.


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.
it's a one liner for babel to pick up a default gateway injected by dhcp 
or dhcpv6.




* 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  for subnet 
allocation". If you don't like OSPF, you don't like zOSPF.


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

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


And me, AHCP + babel...




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


 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.



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 magn

Re: [homenet] other routing options

[Acee Lindem]

On Nov 23, 2011, at 2:29 AM, Randy Turner wrote:

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

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

Thanks,
Acee 


> 
> R.
> 
> On Nov 22, 2011, at 11:10 PM, Randy Turner wrote:
> 
>> 
>> 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.
>> 
>> On Nov 22, 2011, at 10:45 PM, Fred Baker wrote:
>> 
>>> 
>>> On Nov 22, 2011, at 2:49 PM, Randy Turner wrote:
>>> 
 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.
>>> 
>>> 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.
>>> ___
>>> homenet mailing list
>>> homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>>> 
>> 
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet



smime.p7s
Description: S/MIME cryptographic signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Randy]

I would expect AV traffic to dominate homenet, more V than A. 

And I "+1" Mark's earlier comment about  autoconfig being the real challenge. I 
have assumed this from the start.

R.

 Ray Hunter  wrote: 

 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  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?

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.

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
| laur...@touta.in         | laurent.tout...@telecom-bretagne.eu    |
+--++
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Ray Hunter]

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 > 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?

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.


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

| laur...@touta.in | laurent.tout...@telecom-bretagne.eu|
+--++
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Mark Townsley]

On Nov 23, 2011, at 8:10 AM, Randy Turner wrote:

> 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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Laurent Toutain]

On Tue, Nov 22, 2011 at 23:36, Howard, Lee  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?
>
> 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.
>

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
| laur...@touta.in | laurent.tout...@telecom-bretagne.eu|
+--++
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Randy Turner]

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.

On Nov 22, 2011, at 11:10 PM, Randy Turner wrote:

> 
> 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.
> 
> On Nov 22, 2011, at 10:45 PM, Fred Baker wrote:
> 
>> 
>> On Nov 22, 2011, at 2:49 PM, Randy Turner wrote:
>> 
>>> 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.
>> 
>> 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.
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Randy Turner]

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.

On Nov 22, 2011, at 10:45 PM, Fred Baker wrote:

> 
> On Nov 22, 2011, at 2:49 PM, Randy Turner wrote:
> 
>> 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.
> 
> 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.
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Fred Baker]

On Nov 22, 2011, at 2:49 PM, Randy Turner wrote:

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

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.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Fred Baker]

On Nov 22, 2011, at 2:36 PM, Howard, Lee 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.

Makes sense to me.

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

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

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

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

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

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.

> 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.
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] other routing options

[Randy Turner]

"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:

> 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.
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet