Subject: Re: [homenet] Question for you

From: Fred Baker <[email-masked]>
Date: Fri, 30 Sep 2011 21:26:04 +0300

As I understand it, we have made the case that there is a place for routing in at least some homes and in SOHO networks, and we should say what protocols manufacturers should consider implementing in equipment they sell. Two significant parts of the issue there, as you know, are operational expense and cost of goods. Margins in residential routers are thin enough that manufacturers (one of which you know from the inside) essentially lose their entire profit margin if they pick up the phone for a trouble call, and in addition the memory to store the code and data, and the code itself, cost money on a COGS basis. Manufacturers want to be able to buy trouble-free code for a predictable price, put it in the system, and forget the system.

Which argues for proven specifications and implementations that have been field proven to interoperate when used in anger.

To my knowledge, this doesn't automatically imply "give me that old time religion". It does call for proven (and preferably documented) interoperability between numerous independent complete implementations, or proven interoperability of a common profile of a protocol, an exercise I have suggested to some proponents of your favorite protocol is good for the soul. RFC 1246 comes to mind.

By the way, let me clarify a point that you may be confused on. There are detailed interoperability reports for RIPv2, OSPFv2, BGP[1234], and I think IPv4/IS-IS. To my knowledge, there has been interoperability testing of RIPng, OSPFv3, BGP-for-IPv6, and IPv6/IS-IS, all of which are in use in production networks, but the test documentation is a trifle thin. So I'm not asking of your favorite protocol or a dozen others that one could discuss something I think should let slide for the traditional ones. I am simply asking that the claims for the protocols be backed with interoperability testing, RFCs, Security Directorate reviews, and so on.

On Sep 30, 2011, at 11:18 AM, Pascal Thubert (pthubert) wrote:

> Hello Cedric:
> 
> I have the same questions. Furthermore, I'd wish to understand better:
> 
> *** whether the goal is limited to provide a best practice based on "established" ICT technologies 
> 
> There are other "established" technologies. For instance there is extensive networking experience in industrial networks, solving different problems under different constraints. Same goes in AMI/AMR networks, and to a lesser extent in Home, commercial and building automation. Some groups in the IETF have finally started to pay attention and build on that experience. Even if the resulting technologies (e.g. ZigbeeIP and ISA100.11a) are fairly recent, the scale is such that over a few years we have seen unprecedented amounts of implementations, interop and compliance tests (e.g. under IPSO and WCI).
> 
> Also, if we map home use cases with the routing technologies that applied today, we see that at the moment the traditional IGPs do not play much role, at least from the home standpoint:
> - Internet to Home (Content consumption) is not a Home problem
> - Home to Internet (metering, P2P)  is a default route
> - Home to Home (Content and Access sharing) is dominated by OLSR.
> - Inside Home (Content and Device sharing) is single subnet, solved reactively by ARP or ND.
> - Inside Home (Command & Control, Automation) meshing is proprietary though going 6LoWPAN and RPL.
> 
> In any fashion, we can solve an additional problem of our own making that would require our beloved ICT IGPs to be injected in the Home network with always-on routers in each room or we can start producing best practices on how the above can to be done with the technologies that are already in place. Or both?
> 
> *** whether we have an assumption of a plethora of power
> 
> Year over year, we've seen the simplest devices migrate from a totally-switched-off mode to some more and more power greedy sleeping and always-on modes.
> Always-on displays and LEDs appears fancy to the consumer but are of consequence on the family budget and at the scale of a city, result in measurable pollution. 
> And we've been connecting more and more devices to the home power distribution, devices that would not exist 10-20 years ago.
> We know how power-greedy traditional ICT technologies are; people do not want a new heating system that they cannot even stop in summer.
> My take is that whatever this group produces has to be justified in terms of power budget as it has to be justified in other terms like usability and security.
> 
> 
> *** if HOMENET is targeting home gateways and large home cinema gear only, and whether we have an assumption of cat 5/6 cabling
> 
> This case is probably the low hanging fruit and that there is an immediate need to solve a number of problems there. If that's what the group is pursuing for the time being, well, that's fine as long as it's very clear to everybody. But the rest of the world is low power and lossy. Apart from certain ecological niches (that's datacenter mostly) about all Internet-connected devices have evolved the wireless trait, even if the most traditional devices can still use wires. The new trait has lowered dramatically the cost and complexity of accessing the Internet, which in turn allowed the introduction of new species of internet-connected devices that now thrive under the name of Things. At some point we'll have to address that too.
> 
> I do not know how that converts into cents at the current rate...
> 
> Pascal
> 
> -----Original Message-----
> From: C Chauvenet [mailto:[email-masked]] 
> Sent: jeudi 29 septembre 2011 17:23
> To: Acee Lindem; Fred Baker (fred)
> Cc: Mark Townsley; Pascal Thubert (pthubert); MANET IETF; [email-masked]; [email-masked]
> Subject: RE: [homenet] Question for you
> 
> Hi, 
> 
> " I don't think my wife would want a lossy network in our house ;^)" : 
> 
> Nobody wants a lossy network, but the technology you are using may create lossy links...
> 
> I may have miss something in the Homenet scope.
> 
> In the scope of Homenet, is every device in the house runing over a *robust* link (Bit Error Rate below 1 % at the PHY level) ?
> 
> Furthermore do these devices could have some high Power/Computation/Size/Cost constraints ?
> 
> I fail to see the kind of technologies and devices that are targeting.
> 
> Thanks for the clarification.
> 
> Cédric .
> 
> -----Message d'origine-----
> De : Acee Lindem [mailto:[email-masked]] Envoyé : jeudi 29 septembre 2011 16:44 À : Fred Baker Cc : Mark Townsley; C Chauvenet; Pascal Thubert (pthubert); MANET IETF; [email-masked]; [email-masked] Objet : Re: [homenet] Question for you
> 
> I'm in complete agreement with Fred. The areas where the existing link-state protocols may need to be extended are auto-configuration and, potentially, inter-area policies.  
> I don't think my wife would want a lossy network in our house ;^) Thanks, Acee On Sep 28, 2011, at 11:43 AM, Fred Baker wrote:
> 
>> 
>> On Sep 28, 2011, at 5:58 PM, Mark Townsley wrote:
>> 
>>> Since you asked, *I* think that a homenet has functional overlap (what I called "at least a smaller and slightly different subset" in my email) in terms of requirements to LLNs. At first blush, it looks like RPL has lots of functionality - perhaps more than we really need for homenet, and by your own admission more than you need for LLN's - but will hold reservation on what I think best fits the bill until we see Fred's analysis, hear from others, etc. 
>> 
>> My two yen, which may be all it's worth...
>> 
>> If I were a Linksys/D-Link/NetGear/* product manager asking about what protocols to put in, I wouldn't be asking about what still exists in Internet Drafts and is thought by the engineers designing it to be better than sliced bread, but about what was inexpensive to implement, likely to be close to bug-free, and definitively accomplished the goal. I note that most routers for the IPv4 residential routing marketplace implement RIPv2; I know of one that implements no routing protocol, one that implements RIPv2 and RIPv1 (!), and one that implements RIPv2 and OSPF (don't ask which they are, I don't remember). This is from a google search of residential routers a few months ago and covered perhaps 20 products from half as many vendors. So my first inclination is to say that for a residential IPv6 network, RIPng is probably an image match for those vendors.
>> 
>> I have a personal bias in the direction of OSPF or IS-IS; I think that once the code is debugged, SPF-based protocols are more stable (no count-to-infinity), given a reasonable set of defaults generate far more stable networks, and definitively know when there is more than one router on a LAN, which can be important in subnet distribution. 
>> 
>> My first choice would NOT be something that isn't proven in the field in multiple interoperable implementations. 
>> 
>> As a person thinking about making a recommendation, I'd suggest that folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask themselves why that level of interoperability isn't mandatory.
>> _______________________________________________
>> homenet mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/homenet
> 
> 
>

---

From: Don Sturek <[email-masked]>
Date: Sat, 01 Oct 2011 07:38:12 -0700

To add one more point to Fred's note:  I think it is important to get a
commercial group like Wi-Fi to participate in Homenet, adopt some or all
of the drafts/RFCs then sponsor interoperability testing.

I agree with Fred that having individual CPE vendors cobbling together
RFCs will not yield a bullet proof home networking solution and that will
kill the work in Homenet if customer support is needed.

Don

On 9/30/11 11:26 AM, "Fred Baker" <[email-masked]> wrote:

>As I understand it, we have made the case that there is a place for
>routing in at least some homes and in SOHO networks, and we should say
>what protocols manufacturers should consider implementing in equipment
>they sell. Two significant parts of the issue there, as you know, are
>operational expense and cost of goods. Margins in residential routers are
>thin enough that manufacturers (one of which you know from the inside)
>essentially lose their entire profit margin if they pick up the phone for
>a trouble call, and in addition the memory to store the code and data,
>and the code itself, cost money on a COGS basis. Manufacturers want to be
>able to buy trouble-free code for a predictable price, put it in the
>system, and forget the system.
>
>Which argues for proven specifications and implementations that have been
>field proven to interoperate when used in anger.
>
>To my knowledge, this doesn't automatically imply "give me that old time
>religion". It does call for proven (and preferably documented)
>interoperability between numerous independent complete implementations,
>or proven interoperability of a common profile of a protocol, an exercise
>I have suggested to some proponents of your favorite protocol is good for
>the soul. RFC 1246 comes to mind.
>
>By the way, let me clarify a point that you may be confused on. There are
>detailed interoperability reports for RIPv2, OSPFv2, BGP[1234], and I
>think IPv4/IS-IS. To my knowledge, there has been interoperability
>testing of RIPng, OSPFv3, BGP-for-IPv6, and IPv6/IS-IS, all of which are
>in use in production networks, but the test documentation is a trifle
>thin. So I'm not asking of your favorite protocol or a dozen others that
>one could discuss something I think should let slide for the traditional
>ones. I am simply asking that the claims for the protocols be backed with
>interoperability testing, RFCs, Security Directorate reviews, and so on.
>
>> There are other "established" technologies. For instance there is
>>extensive networking experience in industrial networks, solving
>>different problems under different constraints. Same goes in AMI/AMR
>>networks, and to a lesser extent in Home, commercial and building
>>automation. Some groups in the IETF have finally started to pay
>>attention and build on that experience. Even if the resulting
>>technologies (e.g. ZigbeeIP and ISA100.11a) are fairly recent, the scale
>>is such that over a few years we have seen unprecedented amounts of
>>implementations, interop and compliance tests (e.g. under IPSO and WCI).
>> 
>> Also, if we map home use cases with the routing technologies that
>>applied today, we see that at the moment the traditional IGPs do not
>>play much role, at least from the home standpoint:
>> In any fashion, we can solve an additional problem of our own making
>>that would require our beloved ICT IGPs to be injected in the Home
>>network with always-on routers in each room or we can start producing
>>best practices on how the above can to be done with the technologies
>>that are already in place. Or both?
>> 
>> Year over year, we've seen the simplest devices migrate from a
>>totally-switched-off mode to some more and more power greedy sleeping
>>and always-on modes.
>> Always-on displays and LEDs appears fancy to the consumer but are of
>>consequence on the family budget and at the scale of a city, result in
>>measurable pollution.
>> And we've been connecting more and more devices to the home power
>>distribution, devices that would not exist 10-20 years ago.
>> We know how power-greedy traditional ICT technologies are; people do
>>not want a new heating system that they cannot even stop in summer.
>> My take is that whatever this group produces has to be justified in
>>terms of power budget as it has to be justified in other terms like
>>usability and security.
>> 
>> 
>> *** if HOMENET is targeting home gateways and large home cinema gear
>>only, and whether we have an assumption of cat 5/6 cabling
>> 
>> This case is probably the low hanging fruit and that there is an
>>immediate need to solve a number of problems there. If that's what the
>>group is pursuing for the time being, well, that's fine as long as it's
>>very clear to everybody. But the rest of the world is low power and
>>lossy. Apart from certain ecological niches (that's datacenter mostly)
>>about all Internet-connected devices have evolved the wireless trait,
>>even if the most traditional devices can still use wires. The new trait
>>has lowered dramatically the cost and complexity of accessing the
>>Internet, which in turn allowed the introduction of new species of
>>internet-connected devices that now thrive under the name of Things. At
>>some point we'll have to address that too.
>> 
>> In the scope of Homenet, is every device in the house runing over a
>>*robust* link (Bit Error Rate below 1 % at the PHY level) ?
>> 
>> Furthermore do these devices could have some high
>>Power/Computation/Size/Cost constraints ?
>> 
>> De : Acee Lindem [mailto:[email-masked]] Envoyé : jeudi 29
>>septembre 2011 16:44 À : Fred Baker Cc : Mark Townsley; C Chauvenet;
>>Pascal Thubert (pthubert); MANET IETF; [email-masked]; [email-masked]
>>Objet : Re: [homenet] Question for you
>> 
>> I'm in complete agreement with Fred. The areas where the existing
>>link-state protocols may need to be extended are auto-configuration and,
>>potentially, inter-area policies.
>> I don't think my wife would want a lossy network in our house ;^)
>>Thanks, Acee On Sep 28, 2011, at 11:43 AM, Fred Baker wrote:
>> 
>>> 
>>>> Since you asked, *I* think that a homenet has functional overlap
>>>>(what I called "at least a smaller and slightly different subset" in
>>>>my email) in terms of requirements to LLNs. At first blush, it looks
>>>>like RPL has lots of functionality - perhaps more than we really need
>>>>for homenet, and by your own admission more than you need for LLN's -
>>>>but will hold reservation on what I think best fits the bill until we
>>>>see Fred's analysis, hear from others, etc.
>>> 
>>> If I were a Linksys/D-Link/NetGear/* product manager asking about what
>>>protocols to put in, I wouldn't be asking about what still exists in
>>>Internet Drafts and is thought by the engineers designing it to be
>>>better than sliced bread, but about what was inexpensive to implement,
>>>likely to be close to bug-free, and definitively accomplished the goal.
>>>I note that most routers for the IPv4 residential routing marketplace
>>>implement RIPv2; I know of one that implements no routing protocol, one
>>>that implements RIPv2 and RIPv1 (!), and one that implements RIPv2 and
>>>OSPF (don't ask which they are, I don't remember). This is from a
>>>google search of residential routers a few months ago and covered
>>>perhaps 20 products from half as many vendors. So my first inclination
>>>is to say that for a residential IPv6 network, RIPng is probably an
>>>image match for those vendors.
>>> 
>>> I have a personal bias in the direction of OSPF or IS-IS; I think that
>>>once the code is debugged, SPF-based protocols are more stable (no
>>>count-to-infinity), given a reasonable set of defaults generate far
>>>more stable networks, and definitively know when there is more than one
>>>router on a LAN, which can be important in subnet distribution.
>>> 
>>> My first choice would NOT be something that isn't proven in the field
>>>in multiple interoperable implementations.
>>> 
>>> As a person thinking about making a recommendation, I'd suggest that
>>>folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask
>>>themselves why that level of interoperability isn't mandatory.
>manet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/manet

---

From: Fred Baker <[email-masked]>
Date: Sun, 2 Oct 2011 08:20:32 +0800

> of the drafts/RFCs then sponsor interoperability testing.

That would be very interesting.

---

From: Mark Townsley <[email-masked]>
Date: Mon, 3 Oct 2011 04:11:41 +0200

> of the drafts/RFCs then sponsor interoperability testing.

I am constantly amazed at the plethora of consumer-oriented standards groups/forums/logos/associations/etc...

We've had decent uptake of RFC 6204 and other products of v6ops targeting the consumer space. I hope that continues. 

Of course, anyone with specific ties into any of the organizations that might want to use our work, please feel free to help make that happen.

- Mark

---

From: JP Vasseur <[email-masked]>
Date: Mon, 3 Oct 2011 16:01:50 +0200

> I have a personal bias in the direction of OSPF or IS-IS; I think that once the code is debugged, SPF-based protocols are more stable (no count-to-infinity), given a reasonable set of defaults gene…

I spent enough years on OSPF and ISIS to agree with you that these protocols are well proven, widely deployed with the number of 
recent improvements (MTR, fast convergence, …) to name a few are particularly appealing. But before choosing a routing protocol
the first step consists of listing the requirements. In LLN, as you rightly pointed out, "smart objects" have a set of constraints in terms
of resources … far from where we are on traditional routers … Thus I would strongly encourage to list the set of requirements for this
type of devices before making any sort of selection on the routing protocol of choice, taking into account where we will be in a few years
when the number of these objects will not be limited to a few dozens, the LSDB *will* grow …

---

From: JP Vasseur <[email-masked]>
Date: Mon, 3 Oct 2011 16:09:17 +0200

100% agreeing with you Don.

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 3 Oct 2011 16:19:12 +0200

trimming the cc: list a bit
On Mon, Oct 3, 2011 at 4:01 PM, JP Vasseur <[email-masked]> wrote:
<snip>

> when the number of these objects will not be limited to a few dozens, the LSDB *will* grow …

As I see it, we are trying to limit our options of routing protocols
down to a few that can/should/might be implemented in HOMENET devices.

Again, as I see it, there are two ways to get there, no idea which are
the best, probably both

1.) (you suggested) create a list over requirements
2.) (Fred working on) create a list over all possible (and not
possible) routing protocols

why don't you start listing some suggestions for requirements while
Fred create his list? I'm quite sure we'll end up with one good
documented list:-)

(I don't know enough of possible requirements yet to list any...)

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Acee Lindem <[email-masked]>
Date: Mon, 3 Oct 2011 10:24:26 -0400

Hey JP,

> when the number of these objects will not be limited to a few dozens, the LSDB *will* grow … 

I think a viable option for 2012 is that if the LLN networks with their smart objects have to connect to the traditional HOMENET fixed and wireless networks, they will need to do so through a border router supporting both environments. IMHO, we don't need one protocol that meets all requirements for every possible device in the home. 

Thanks,
Acee

---

From: JP Vasseur <[email-masked]>
Date: Mon, 3 Oct 2011 16:27:02 +0200

Hey Acee,

> I think a viable option for 2012 is that if the LLN networks with their smart objects have to connect to the traditional HOMENET fixed and wireless networks, they will need to do so through a borde…

100% agreeing with you !! This is why I was limiting my comments to "constrained objects" - Very much in line with you.

Cheers.

JP.

---

From: Qiong <[email-masked]>
Date: Mon, 3 Oct 2011 23:33:06 +0800

Hi, Acee,

Agree. I think the HOMENET requirements should be derived from major devices
in the home network scenario. Maybe currently we should firstly focus on
multiple router scenario for traditional fixed and wireless network for
multiple services (especially WiFi) , and then introduce LLN network as well
for smart objects in the same environment, together with the homenet
architecture and new model in the future.

Best wishes

Qiong

>
> I think a viable option for 2012 is that if the LLN networks with their
> smart objects have to connect to the traditional HOMENET fixed and wireless
> networks, they will need to do so through a border router supporting both
> environments. IMHO, we don't need one protocol that meets all requirements
> for every possible device in the home.
>
> Thanks,
> Acee
>
>
>
> >
> >>

---

From: Tony Li <[email-masked]>
Date: Mon, 3 Oct 2011 09:15:58 -0700

The problem with a RIP like protocol is that it will have RIP like convergence properties.  IMHO, that's no longer acceptable.

Doing a subset of a LS protocol with a trivial default configuration should not be unreasonable.

Tony

On Oct 3, 2011, at 8:58 AM, Randy Turner wrote:

> 
> I would hope that we would NOT be seriously considering OSPF or IS-IS in the home...this seems like using a sledgehammer to kill an ant.  How many routes are we talking about for a home network?  I don't believe any enterprise routing protocol was designed for a "zeroconf" or "zeroadmin" type of environment.  Our customers won't even know what an IP address is.
> 
> Seems like a "RIP-like" (around the same scope of complexity) would be enough for a homenet.  I'm curious to see what comes out of the LLN discussion.
> 
> The "filter" for any of these decisions should probably always be a "zeroconf" or "zeroadmin" scenario -- if a proposed approach to a problem can't exist in a "zeroconf/admin" environment, then I would think it would not be the right choice.  Also, as a "first cut" solution, we I think we should be focused on the 80% use-case, not the fringe.  The participants of this working group, and their respective home networking setups, are probably not our "typical" customer. 
> 
> Randy
> 
> 
> On Oct 3, 2011, at 8:33 AM, Qiong wrote:
> 
>> Hi, Acee,
>> 
>> Agree. I think the HOMENET requirements should be derived from major devices in the home network scenario. Maybe currently we should firstly focus on multiple router scenario for traditional fixed and wireless network for multiple services (especially WiFi) , and then introduce LLN network as well for smart objects in the same environment, together with the homenet architecture and new model in the future. 
>> 
>> Best wishes 
>> 
>> Qiong 
>> 
>> 
>> 
>> 
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 3 Oct 2011 09:38:20 -0700

On Mon, Oct 3, 2011 at 08:33, Qiong <[email-masked]> wrote:

> Agree. I think the HOMENET requirements should be derived from major
> devices in the home network scenario. Maybe currently we should firstly
> focus on multiple router scenario for traditional fixed and wireless network
> for multiple services (especially WiFi)
>

Agreed. While it's nice to think about abstract requirements and go off and
pick a protocol that meets all of them, the truth is that if it doesn't get
implemented, there's no point in doing so. If any of this is to be exist in
the real world, then we need to start from the capabilities of devices that
are currently common in home networking environments, because it's in those
devices that this technology will be implemented first, if at all.

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 28 Sep 2011 10:54:23 -0700

On Wed, 2011-09-28 at 16:58 +0200, Mark Townsley wrote:
> 
> >> The majority of IP-based home networks today are neither
> power-constrained nor particularly lossy. 

I would agree that that is the case today, but suggest we look ahead a
bit.

There's a fair head of steam building in emergency services that has the
term 'broadband' attached to it.  Lots of confusion, but...

We're about to see a repeat of what we saw in the CATV market where the
vendors thought you'd connect a computer at home to the DOCSIS network.
But we all hooked up routers instead.  This time the story is the
cellphone folks rolling out '4G' network segments and naively thinking
that we'll just hook up cellphones (which have since become computers --
mine has 8G of RAM in it!).  

Scenario for orientation.  Instead of the EMT in the ambulance having a
cellphone to call the emergency room, the EMT will be armed with several
diagnostic gadgets attached to a LAN (either ethernet or WiFi).  And a
router.  The router will, in turn be linked to the rest of internet with
a radio-WAN.  

Scenario implications.  Right now, emergency services tend to rely on a
set of high sites -- Monterey County where I live, has eleven.  But the
broadband technologies all look better with an order of magnitude more
sites (think schoolhouse roofs) and consequently more handoffs (aka
routing table volatility).  

Topology.  The radio-WAN is in interior of internet, not fringe.
	Power-constrained -- probably not much change since a lot of this will
be vehicle-mount -- ambulances, fire engines, etc.  This all changes as
soon as the trooper dismounts and exceeds WiFi range from his vehicle.
	Lossy.  Depends on how you define the term...  But radios lose more
bits (and hence more packets) than wires.

---

From: Randy Turner <[email-masked]>
Date: Mon, 3 Oct 2011 08:58:37 -0700

Randy

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 3 Oct 2011 09:50:27 -0700

On Mon, Oct 3, 2011 at 08:58, Randy Turner <[email-masked]>wrote:

> I would hope that we would NOT be seriously considering OSPF or IS-IS in
> the home...this seems like using a sledgehammer to kill an ant.
>

If the devices we're talking about have enough resources to run them, and
they have desirable properties that are useful in home networks, then what's
the problem with either of these? Home gateways these days are capable of
1Gbps hardware forwarding and have pretty fast CPUs.

For example, if there were a robust open-source version of IS-IS that didn't
take up too much RAM and flash, you could define TLVs to implement zeroconf
and you could get to something that works relatively quickly.

---

From: Diego G <[email-masked]>
Date: Mon, 3 Oct 2011 17:01:21 +0000

I want to cancel my subscription to this mailing list.

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 3 Oct 2011 13:11:38 -0400

You do that by...

> I want to cancel my subscription to this mailing list.

^--- following the instructions there.

Regards
Marshall Eubanks

---

From: Robert Cragie <[email-masked]>
Date: Mon, 3 Oct 2011 18:24:06 +0100

+1

Robert

On Mon, Oct 3, 2011 at 3:24 PM, Acee Lindem <[email-masked]>wrote:

> >>> Since you asked, *I* think that a homenet has functional overlap (what
> I called "at least a smaller and slightly different subset" in my email) in
> terms of requirements to LLNs. At first blush, it looks like RPL has lots of
> functionality - perhaps more than we really need for homenet, and by your
> own admission more than you need for LLN's - but will hold reservation on
> what I think best fits the bill until we see Fred's analysis, hear from
> others, etc.
> >>
> Internet Drafts and is thought by the engineers designing it to be better
> than sliced bread, but about what was inexpensive to implement, likely to be
> close to bug-free, and definitively accomplished the goal. I note that most
> routers for the IPv4 residential routing marketplace implement RIPv2; I know
> of one that implements no routing protocol, one that implements RIPv2 and
> RIPv1 (!), and one that implements RIPv2 and OSPF (don't ask which they are,
> I don't remember). This is from a google search of residential routers a few
> months ago and covered perhaps 20 products from half as many vendors. So my
> first inclination is to say that for a residential IPv6 network, RIPng is
> probably an image match for those vendors.
> >>
> count-to-infinity), given a reasonable set of defaults generate far more
> stable networks, and definitively know when there is more than one router on
> a LAN, which can be important in subnet distribution.
> >
> > I spent enough years on OSPF and ISIS to agree with you that these
> protocols are well proven, widely deployed with the number of
> > recent improvements (MTR, fast convergence, …) to name a few are
> particularly appealing. But before choosing a routing protocol
> > the first step consists of listing the requirements. In LLN, as you
> rightly pointed out, "smart objects" have a set of constraints in terms
> > of resources … far from where we are on traditional routers … Thus I
> would strongly encourage to list the set of requirements for this
> > type of devices before making any sort of selection on the routing
> protocol of choice, taking into account where we will be in a few years

-- 

Robert Cragie

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com

---

From: Randy Turner <[email-masked]>
Date: Mon, 3 Oct 2011 10:59:21 -0700

I agree that RIP does have issues, but in a constrained-number-of-routes scenario (like home networking), it may be "good enough"

That being said, a "subset" implementation of an LS solution that takes into account zeroconf/zeroadmin requirements would certainly be better than anything RIP-like.

Maybe this "subset" profile of an LS protocol with zeroconf/zeroadmin requirements should be our focus?  I would still like to hear the outcome of any discussions regarding
self-organizing routes, which would seem to benefit the zeroconf/zeroadmin goal...

Randy

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 03 Oct 2011 22:22:51 +0200

<Trimming cc list>

Hi Ulrich,

Can you also say the opposite that rotocols developed for wireless work 
equally well also for wired environments ? If so let me ask why do we 
need both classes of routing protocols ?

If not I am not sure homenet should focus on wireless router to router 
communication at all. Yes I am in favor of wired env with fiber or with 
nice cat 7 wiring between my routers.

Cheers,
R.

> I agree with Jim. The reason why we developed OLSR and the its
> successor OLSRv2 was precisely that wireless environments are very
> different from wired. There are plenty of deployments of OLSR and
> several of OLSRv2, with up to several hundreds of wireless routers, so
> it is demonstrably working.
>
> Regards
> Ulrich

---

From: Russ White <[email-masked]>
Date: Mon, 03 Oct 2011 16:45:25 -0400

> need both classes of routing protocols ?

I would argue that the OSPF MANET extensions would work just as well for
IS-IS or OSPF in both wirelss and wired networks.

> nice cat 7 wiring between my routers.

I am as well, but I think we should allow for both with a single
protocol as much as possible. I think OSPF or IS-IS (or even EIGRP) can
be adapted to the low power/lossy network situation, it just takes some
thought and care.

Russ

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 3 Oct 2011 13:53:42 -0700

Hi,

>> need both classes of routing protocols ?

I have deployed OLSRv2 both on Ethernet and on wireless environments,
without problems. I do not see a reason why OLSRv2 could not run in
mixed environments.

> IS-IS or OSPF in both wirelss and wired networks.

The OSPF MANET extensions would certainly be a valid alternative to
consider. Which one performs better or is more suited (OLSRv2 /
OSPF+MANET / ...) -- I don't know, that would be an interesting
comparison.

> protocol as much as possible.

I agree. Not everyone likes long cables in a home environment. And
having a single protocol would be indeed better.

> I think OSPF or IS-IS (or even EIGRP) can

We have invested that thought and care in MANET for years now. I think
it could be worth investing the suitability of the protocols developed
in MANET (as well as the OSPF MANET extensions), before reinventing
the wheel.

Ulrich

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 3 Oct 2011 11:22:30 -0700

Hi Tony,

I agree. I would like to mention that we are specifying an extensible,
flexible (using TLVs) LS protocol in the MANET WG: OLSRv2. I think that we
are not far from submitting it to the IESG. OLSRv2 could well operate on
home devices with limited resources, and does not have the issues of RIP.

Regards
Ulrich

On Mon, Oct 3, 2011 at 9:15 AM, Tony Li <[email-masked]> wrote:

>
> The problem with a RIP like protocol is that it will have RIP like
> convergence properties.  IMHO, that's no longer acceptable.
>
> the home...this seems like using a sledgehammer to kill an ant.  How many
> routes are we talking about for a home network?  I don't believe any
> enterprise routing protocol was designed for a "zeroconf" or "zeroadmin"
> type of environment.  Our customers won't even know what an IP address is.
> >
> > Seems like a "RIP-like" (around the same scope of complexity) would be
> enough for a homenet.  I'm curious to see what comes out of the LLN
> discussion.
> >
> > The "filter" for any of these decisions should probably always be a
> "zeroconf" or "zeroadmin" scenario -- if a proposed approach to a problem
> can't exist in a "zeroconf/admin" environment, then I would think it would
> not be the right choice.  Also, as a "first cut" solution, we I think we
> should be focused on the 80% use-case, not the fringe.  The participants of
> this working group, and their respective home networking setups, are
> probably not our "typical" customer.
> >
> > Randy
> >
> >
> for multiple services (especially WiFi) , and then introduce LLN network as
> well for smart objects in the same environment, together with the homenet

---

From: Tony Li <[email-masked]>
Date: Mon, 3 Oct 2011 11:25:55 -0700

What's the rationale for not subsetting OSPF or IS-IS?

Tony

On Oct 3, 2011, at 11:22 AM, Ulrich Herberg wrote:

> Hi Tony,
> 
> I agree. I would like to mention that we are specifying an extensible, flexible (using TLVs) LS protocol in the MANET WG: OLSRv2. I think that we are not far from submitting it to the IESG. OLSRv2 could well operate on home devices with limited resources, and does not have the issues of RIP.
> 
> Regards
> Ulrich 
>

---

From: Jim Gettys <[email-masked]>
Date: Mon, 03 Oct 2011 14:28:06 -0400

I think there is another set of routing issues that most have not
thought about unless they have had experience with wireless networking;
that is the possible need for diversity aware routing.

See:

http://www.pps.jussieu.fr/~jch/software/babel/wbmv4.pdf
<http://www.pps.jussieu.fr/%7Ejch/software/babel/wbmv4.pdf>

For an introduction to the topic, and some work in the area (e.g. babelz).

In my house, for example, I have great trouble getting wires where all I
need them, and I need multiple access points.  I'd like to put one out
in the pool shed, and I really can't get wires out there (without digging).

This may or may not be orthogonal to the routing requirements to support
multi-homing and multiple providers, but is something that many/most
routing protocols have not dealt with in the past.
                        - Jim

---

From: Tony Li <[email-masked]>
Date: Mon, 3 Oct 2011 11:35:36 -0700

LS protocols give every router a full picture of the topology, so the diversity is apparent to all nodes.

Tony

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 3 Oct 2011 11:42:38 -0700

Hi Tony,

One reason for using OLSRv2 instead of OSPF is that it is optimized for
wireless radio (fewer transmissions, optimized flooding, link
bidirectionality check, compressed packet format, IPv6 support). Its TLV
structure allows for extending the protocol easily (and for encapsulating
other, arbitrary, data into control traffic messages). I assume that not all
routers are required to be connected by cable in HOMENET, but some could be
wireless (please correct me if I am wrong here...).

I am not saying that OSPF is not (or less) suitable for these cases, but it
may be worth considering the work done in MANET for HOMENET.

Regards
Ulrich

On Mon, Oct 3, 2011 at 11:25 AM, Tony Li <[email-masked]> wrote:

> > > I would hope that we would NOT be seriously considering OSPF or IS-IS
> in the home...this seems like using a sledgehammer to kill an ant.  How many
> > >> I think a viable option for 2012 is that if the LLN networks with
> their smart objects have to connect to the traditional HOMENET fixed and
> wireless networks, they will need to do so through a border router
> supporting both environments. IMHO, we don't need one protocol that meets
> all requirements for every possible device in the home.
> > >>
> > >> Thanks,
> > >> Acee
> > >>
> > >>
> > >>
> > >> >
> > >> >>
> > >> >> My first choice would NOT be something that isn't proven in the
> field in multiple interoperable implementations.
> > >> >>
> > >> >> As a person thinking about making a recommendation, I'd suggest
> that folks read https://tools.ietf.org/html/rfc2026#section-4.1.2 and ask

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 03 Oct 2011 20:49:09 +0200

One thing I am perhaps missing in this thread ...

Why a wireless access point at the pool has to also be a router ? Isn't 
it sufficient to extend one or more layer 2 to it ?

Thx,
R.

---

From: Jim Gettys <[email-masked]>
Date: Mon, 03 Oct 2011 15:10:25 -0400

> LS protocols give every router a full picture of the topology, so the diversity is apparent to all nodes.

My point was just that wireless has a set of challenges that all may not
be familiar with; knowing that may help point the discussion in fruitful
ways.  Routing isn't my area of expertise (though I have scars on my
back from it in wireless...).
                    - Jim

---

From: Tony Li <[email-masked]>
Date: Mon, 3 Oct 2011 12:32:19 -0700

> back from it in wireless...).

Understood.

Yes, wireless has some challenges and I've spent some time in that area.  Certainly our standard protocols are not optimal for a purely wireless environment.  

However, for the generic, heterogenous networks that I would expect in the home, I would expect that the generic protocols would be the better overall approach.

Tony

---

From: Jim Gettys <[email-masked]>
Date: Mon, 03 Oct 2011 15:45:22 -0400

> However, for the generic, heterogenous networks that I would expect in the home, I would expect that the generic protocols would be the better overall approach.

Having been seriously scarred by presuming that wireless was similar to
wired, I'm a believer in careful testing, rather than "expecting" that
something should work.  Without "running code", demonstrably working,
I'll take nothing on faith in this area.

Wireless != wired, is what I took away from that (painful) experience.
                            - Jim

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 3 Oct 2011 13:03:24 -0700

Regards
Ulrich

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 3 Oct 2011 19:28:46 -0700

Michael,

On Mon, Oct 3, 2011 at 6:26 PM, Michael Richardson <[email-masked]> wrote:
>
>>>>>> "Ulrich" == Ulrich Herberg <[email-masked]> writes:
>    Ulrich> arbitrary, data into control traffic messages). I assume
>    Ulrich> that not all routers are required to be connected by cable
>    Ulrich> in HOMENET, but some could be wireless (please correct me if
>    Ulrich> I am wrong here...).
>
> You should assume that essentially all devices with more than one
> possible interface are possible routers.  So my HTC G2 has four
> interfaces: wifi, 3G, Bluetooth PAN, and USB-ethernet.

Yes, that's what I assumed. I would even argue that in the future,
most links will be wireless within the house (and possibly even the
connectivity to the Internet).

> Note that just because my 3G is up and alive, and can be used by my
> phone, doesn't mean that the purpose of it participating in the routing
> is to provide *Internet* to the rest of the house.  It might only be
> talking to my house network to get across it so that it can turn
> activate a light switch...

Yes, but that should not be any problem; it just depends which
prefixes are allocated to and advertised by the routers.

Regards
Ulrich

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Oct 2011 21:26:02 -0400

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Oct 2011 21:27:49 -0400

>>>>> "Robert" == Robert Raszuk <[email-masked]> writes:
    Robert> Why a wireless access point at the pool has to also be a
    Robert> router ? Isn't it sufficient to extend one or more layer 2
    Robert> to it ?

It's not much of an access point if it doesn't have a second interface,
is it?  If it's out at the pool, and it has no wired layer2, then it
might well have a second radio (or a second ESSID), to relay.  But, it
might also be connected to the wired network in the pool house.

---

From: C Chauvenet <[email-masked]>
Date: Tue, 4 Oct 2011 00:45:50 -0700

Hi,

Wired or Wireless is not really the point.
I think we should rather draw a line between the Lossy and the Very Reliable Networks (which is often tight to the power/size/cost constraints).

I think a routing protocol can run over wired or wireless links, as soon as it is a route-over protocol.
The real point is the set of requirements taken into considerations for the design of the routing protocol.

For instance, we use RPL over PLC (wired) and 802.15.4 (wireless) because they both fall in the LLN category (which is indeed not restricted to wireless links).

To my mind it is clear that we have to use a route-over protocol if we consider multiple technologies (which I believe is a correct assumption in a home).

Some examples to illustrate my opinion :

Lossy Wired : Some PLC technologies (See AMI technologies).
Reliable Wired : Ethernet
Lossy Wireless : 802.15.4
Reliable Wireless : Wifi

Finally, I really agree with a previous remark on the list who states that the single magic routing protocol is hard to find.
We may use some routing protocols, depending on the type of devices we think will be used in the home.

A remark about this statement :

"I think OSPF or IS-IS (or even EIGRP) can
be adapted to the low power/lossy network situation, it just takes some
thought and care."

This doesn't seems to be compliant with the protocol survey which has been done by the ROLL WG :

See Figure 1 here : http://tools.ietf.org/html/draft-ietf-roll-protocols-survey-07#page-14

Best,

Cédric.

Le 3 oct. 2011 à 22:53, Ulrich Herberg a écrit :

Hi,

On Mon, Oct 3, 2011 at 1:45 PM, Russ White <[email-masked]<mailto:[email-masked]>> wrote:

Ulrich

Russ

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

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

---

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 04 Oct 2011 12:10:32 +0200

On 03/10/2011 18:50, Lorenzo Colitti wrote:
> On Mon, Oct 3, 2011 at 08:58, Randy Turner <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     I would hope that we would NOT be seriously considering OSPF or IS-IS in the
>     home...this seems like using a sledgehammer to kill an ant.
> 
> 
> If the devices we're talking about have enough resources to run them, and they
> have desirable properties that are useful in home networks, then what's the
> problem with either of these? Home gateways these days are capable of 1Gbps
> hardware forwarding and have pretty fast CPUs.

The problem isn't the CPU but the memory.  Vendors want to stick in as little
(expensive) flash and RAM as possible, and don't want to spend a few $$ for
a few spare meg's of memory that won't be used by most of the customers.

I've created new images for these devices and whenever adding something,
one also had to ask the question what to drop in order for the new code
to fit.  Adding memory generally wasn't an option.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk(at)uijterwaal.nl
                                          http://www.uijterwaal.nl
                                          Phone: +31.6.55861746
------------------------------------------------------------------------------

There appears to have been a collective retreat from reality that day.
                                 (John Glanfield, on an engineering project)

---

From: Fred Baker <[email-masked]>
Date: Tue, 4 Oct 2011 21:50:29 +0800

On Oct 4, 2011, at 12:50 AM, Lorenzo Colitti wrote:

> For example, if there were a robust open-source version of IS-IS that didn't take up too much RAM and flash, you could define TLVs to implement zeroconf and you could get to something that works relatively quickly.

RFC 1453 specified a default OSPF configuration that my (ACC) Router came up with by default. The only configuration necessary was to supply IPv4 prefixes/addresses to the interfaces and to turn OSPF on. In the context of a home, I suspect it would be pretty close. Fundamentals: default values for most attributes are as specified in the OSPF RFC, the metric is the duration of a bit in 10 ns units (which in LAN networks becomes a hop count), and all interfaces are in area zero. Change things to your heart's content, but the default configuration is one that actually works for most purposes in a small network. I'll entertain arguments that this doesn't address every possible configuration, but for the networks we're discussing, I'll argue that its "close enough".

---

From: Chris Elliott <[email-masked]>
Date: Tue, 4 Oct 2011 12:05:20 -0400

> might also be connected to the wired network in the pool house.

Bridging works fine between 802.11 and 802.1--or another 802.11 link. No routing required.

It works for the IETF meeting networks and pretty much how all Enterprise gear is setup.

Let's keep it simple and only route when we have to.

Chris.

--
Chris Elliott
CCIE # 2013 R&S

---

From: Russ White <[email-masked]>
Date: Tue, 04 Oct 2011 15:58:05 -0400

> Let's keep it simple and only route when we have to.

There is a strong argument to be made that routing is simpler in the
mobile space than bridging is... And that routing to the edge in these
cases will actually make interfacing with some of the complex edge
interfaces likely to evolve in the long term much simpler, as well.

While we might not like that someone could have a 3g connection and an
11n connection on the same laptop, or even on a single "pad," this is
the reality. Apple's recent move to "cut off" purchases for "outside
products" through "third party web sites," should show us that there
might be a point where you must go through network a to get content from
them, and network b to get content from them --which is already going to
require routing at the end device, at any rate.

IMHO, we should accept that routing is going to be mixed with bridging
at the end node, and work around that reality.

:-)

Russ

---

From: "Roy, Radhika R USA CIV (US)" <[email-masked]>
Date: Tue, 4 Oct 2011 15:07:05 +0000

Agreed.

Another idea is this: Do we also need any features like mobile ad hoc networking (e.g. OLSR) in homenet?

RRR

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 4 Oct 2011 14:15:44 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Michael Richardson
> Sent: Monday, October 03, 2011 9:28 PM
> To: [email-masked]
> Cc: C Chauvenet; Randy Turner; MANET IETF; Mark Townsley; JP Vasseur;
> Ulrich Herberg; Acee Lindem; Qiong; [email-masked]; [email-masked]
> Subject: Re: [homenet] [manet] Question for you
> 
> 

I don't think that's the answer. It would be perfectly plausible to connect more the 802.11 access point on the same IP subnet as the wired network, or even more than one access point, all tied together at layer 2.

For whatever reason, the 802.11 access points you can actually buy on the market seem to incorporate a router. Seems really silly, when most homes connect one of these to a cable or DSL modem, both of which are also routers, but there you have it. You end up with a stack of private IP address subnets.

Bert

---

From: Chris Elliott <[email-masked]>
Date: Wed, 5 Oct 2011 06:02:17 +0800

> at the end node, and work around that reality.

I absolutely agree you need routing. However, I disagree that your pool AP
needs to route, as Michael postulated. Keep routing in the core, or as
needed
in the case of multi-homed end devices.

However, that pool AP may need access to several subnets. I want my
primary home network, my enterprise home network, and my guest network
all accessible as SSIDs at that pool AP. That means trunking back to the
home router, in my mind. I don't see any references to VLANs or any form
of trunking in the Homenet drafts or the mailing list archives. Am I missing
something?

Chris.

-- 
Chris Elliott
[email-masked]
CCIE # 2013 R&S

---

From: Chris Elliott <[email-masked]>
Date: Wed, 5 Oct 2011 06:09:50 +0800

On Wed, Oct 5, 2011 at 3:15 AM, Manfredi, Albert E <
[email-masked]> wrote:

> I don't think that's the answer. It would be perfectly plausible to connect
> more the 802.11 access point on the same IP subnet as the wired network, or
> even more than one access point, all tied together at layer 2.
>
> For whatever reason, the 802.11 access points you can actually buy on the
> market seem to incorporate a router. Seems really silly, when most homes
> connect one of these to a cable or DSL modem, both of which are also
> routers, but there you have it. You end up with a stack of private IP
> address subnets.
>

Often you can buy an access point or a wireless router. Many wireless
routers have several switched Ethernet ports and a single "WAN" Ethernet
port. Just don't use the "WAN" port and you're bridged. And some wireless
routers (the Apple Airport series, for example) allow you to choose the mode
they run in. They will bridge just fine, if you configure them that way.

Of course, for a home network, routing and bridging and trunks and multiple
SSIDs etc. all need to be configured automatically to a sane state. Two
switches or a router and a switch can automatically trunk if they use a L2
discovery protocol, as can and AP. That same AP can then expose the VLANs on
that trunk as separate SSIDs.

All of this does not seem to be covered by the existing drafts. Are we
assuming someone else will do this work or are we just interested in IPv6
and up?

Chris.

-- 
Chris Elliott
[email-masked]
CCIE # 2013 R&S

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Oct 2011 08:46:17 +0200

Chris;

> Let's keep it simple and only route when we have to.

Certainly, but that's not the point. As long as you have a natively loopless topology, for which a WiFi ESS is a simple example, you can bridge and proxy/relay/repeat all you want. You'll note that the ESS model is reproduced at L3 when the 6LoWPAN backbone router proxies ND from a backbone link onto a LLN.

The problem is that soon enough you'll need more than 1 relay AP between the pool and the lounge. You'll need it to improve throughput through spatial diversity. You'll need it so save power and reduce interferences. You'll need it to improve your delivery ratios.

As soon as you have more than one relay and the connectivity is whatever meshing of links, loops can form and you need routing. This is why we came up with spanning tree and its evolutions in L2 switch networks. And all sorts of L2 mesh technologies in wireless, still L2 specific and proprietary wherever you look at. Then again, the IETF addressed the problem at L3, and came up with the RPL protocol that draws one (or more) loopless topology(ies) upon an arbitrary mesh to reach the gateways.

We can go (again) through lengthy discussions but in short I agree with other voices (Russ) that indicate that we need a L3 routing solution. I also fully agree with the voices (Robert) that indicated that the backbone distribution network and the meshed fringe at the edge are different bests and might need different treatments.

Cheers,

Pascal

---

From: JP Vasseur <[email-masked]>
Date: Wed, 5 Oct 2011 08:30:54 +0200

Sharing some thoughts … as already pointed on this list, we will more likely need two routing protocols,
one of constraint objects (e.g. sensors, actuators, ..), one for the other devices, this is perfectly fine (and
we know that some devices will not need routing at all, fine too). With regards to Smart objects, since the
IETF has already specified a routing protocol (RPL in the ROLL WG), do we now want to "Tweak"/"change"
/Add yet a third one (a simplified LS or routing protocol such as OLSR) ? Since it was mentioned that we 
should select a well established and stabilized routing protocol, it is worth pointing out that although RPL 
is fairly new, in the world of smart objects, this is the protocol that will rapidly get the largest adoption and
experience in the field, see the number of alliances that adopted it (Zigbee/IP, Wave2M, …)

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Oct 2011 09:17:18 +0200

Interestingly, 

Those deployments are not limited to intra-home but include between-homes, as I indicated earlier, for content and access sharing.

Is that scenario in scope for this group?

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ulrich Herberg
Sent: lundi 3 octobre 2011 22:03
To: Jim Gettys
Cc: C Chauvenet; MANET IETF; Mark Townsley; JP Vasseur; Qiong; Acee Lindem; Tony Li; [email-masked]; Lorenzo Colitti; [email-masked]
Subject: Re: [homenet] [manet] Question for you

I agree with Jim. The reason why we developed OLSR and the its successor OLSRv2 was precisely that wireless environments are very different from wired. There are plenty of deployments of OLSR and several of OLSRv2, with up to several hundreds of wireless routers, so it is demonstrably working.

Regards
Ulrich

On Mon, Oct 3, 2011 at 12:45 PM, Jim Gettys <[email-masked]> wrote:
> >> My point was just that wireless has a set of challenges that all 
> >> may not be familiar with; knowing that may help point the 
> >> discussion in fruitful ways.  Routing isn't my area of expertise 
> >> (though I have scars on my back from it in wireless...).
> >
> > Understood.
> >
> Having been seriously scarred by presuming that wireless was similar 
> to wired, I'm a believer in careful testing, rather than "expecting" 
> that something should work.  Without "running code", demonstrably 
> working, I'll take nothing on faith in this area.
>

---

From: Russ White <[email-masked]>
Date: Wed, 05 Oct 2011 06:10:46 -0400

> in the case of multi-homed end devices.

I suspect most all devices are going to be multihomed at some point or
another...

> of trunking in the Homenet drafts or the mailing list archives. Am I missing

We probably need virtualization in the home, as well, for just these
situations. I don't see how you substitute one for the other, though
--unless you're going to push all routing onto the host (and it's always
easier to push the problem someplace else rather than to solve it).

:-)

Russ

>     [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> CCIE # 2013 R&S

---

From: Russ White <[email-masked]>
Date: Wed, 05 Oct 2011 06:13:07 -0400

> we know that some devices will not need routing at all, fine too). 

I would actually prefer to avoid multiple routing protocols in the
home... Every control plane brings a new level of complexity into the
mix, and mixing information from multiple control planes has always been
notoriously difficult and error prone even when done by very smart
humans in rather controlled environments.

No redistribution, in other words, and certainly no automatic
redistribution.

:-)

Russ

---

From: JP Vasseur <[email-masked]>
Date: Wed, 5 Oct 2011 17:13:03 +0200

> No redistribution, in other words, and certainly no automatic

Well if we can find *one* protocol for all devices in home, I am all for it as well.

Cheers.

JP.

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Oct 2011 08:24:31 -0700

-1

The charter already allows for interface to external groups:

---
The working group will also liason with external
standards bodies where it is expected that there are normative
dependencies between the specifications of the two bodies.
---

I.e., this can be handled via liaisons (better, IMO).

Joe

---

From: Fred Baker <[email-masked]>
Date: Thu, 6 Oct 2011 11:00:56 -0400

Not sure that's the same thing. WiFi is an industry organization, not an SDO. Yes, we could send them a letter.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 06 Oct 2011 11:40:51 -0700

In message <[email-masked]>
Fred Baker writes:
 
> Not sure that's the same thing. WiFi is an industry organization, not
> an SDO. Yes, we could send them a letter.

IEEE would be the relevant standards organization, if we had any
relevant input into what is done at layer-2.  IEEE usually sticks to
layer-2 and IETF to layer-3 and up (layer-2.5 if that is what you want
to call MPLS).

We would contact WiFi if we had as idea for logo artwork for an IETF
homenet/manet/roll/rtgwg blessed profile.  This is not typically what
IETF does.

IMHO - neither is a good candidate for a liason relationship.

btw - this message is cross posted to three lists: homenet, manet,
rtgwg.  I suggest we drop the cc to homenet only and anyone on rtgwg
and manet can join homenet and continue the discussion.

In Fred's defense, when he started this thread he asked that responses
be sent to him only and not to the lists.

[I'm not subscribed to manet, so this email may not get there.]

Curtis

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 6 Oct 2011 11:50:52 -0700

Hi Curtis,

Sorry for my off-topic email:

On Thu, Oct 6, 2011 at 11:40 AM, Curtis Villamizar <[email-masked]> wrote:

> [...]

Actually, I would prefer to limit it to one mailing list (e.g. homenet). As
many, like you, are not subscribed to MANET, the MANET chairs or I have to
accept each reply manually because of the mailing list filters (and
currently, there are several emails per day). I have sent an email to the
MANET list that the thread is continued on homenet only, so everyone
interested in the topic may follow the thread there.

Best regards
Ulrich

---

From: "Stephen [kiwin] Palm" <[email-masked]>
Date: Thu, 6 Oct 2011 19:00:40 -0700

Wi-Fi Alliance (WFA) is also a standards setting organization in addition to its marketing role. Relevent work should be liaised to WFA. 
I can help arrange a liaision application. 

Regards, kiwin
-------
Stephen [kiwin] Palm   Ph.D.                     W: http://www.kiwin.com
Senior Technical Director                             T: +1-949-926-PALM
           Broadcom - Broadband Communications Group 

----- Original Message -----
From: Curtis Villamizar [mailto:[email-masked]]
Sent: Thursday, October 06, 2011 11:40 AM
To: Fred Baker <[email-masked]>
Cc: Don Sturek <[email-masked]>; Joe Touch <[email-masked]>; C Chauvenet <[email-masked]>; MANET IETF <[email-masked]>; Mark Townsley <[email-masked]>; Acee Lindem <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: [homenet] liasons and cross posting (was Re: Question for you)

Curtis

---

From: Joel jaeggli <[email-masked]>
Date: Fri, 07 Oct 2011 00:36:43 -0700

> to fit.  Adding memory generally wasn't an option.

one can handily demonstrate ospfv2 and v3 running on an off the shelf
wireless ap platform with 16MB of ram along with the utility necessary
to make it a functional ap/home-gateway.

while memory is or can be tight there are other functional requirements
driving memory utilization as well and how much ram they are built will
depend on the need to pack features in to remain competitive. IF the
could optimize the BOM down to a rock in a box they would but stateful
inspection policy, gigabit ethernet/802.11n mimo buffers usb
ports/support storage/media gateway functionality/ipv6 support etc all
conspire to make the ap you have now have more resources than the one
you had in the past.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Oct 2011 18:44:13 -0400

>>>>> "Rex" == Rex Buddenberg <[email-masked]> writes:
    Rex> Scenario for orientation.  Instead of the EMT in the ambulance
    Rex> having a cellphone to call the emergency room, the EMT will be
    Rex> armed with several diagnostic gadgets attached to a LAN (either
    Rex> ethernet or WiFi).  And a router.  The router will, in turn be
    Rex> linked to the rest of internet with a radio-WAN.

    Rex> Scenario implications.  Right now, emergency services tend to
    Rex> rely on a set of high sites -- Monterey County where I live,
    Rex> has eleven.  But the broadband technologies all look better
    Rex> with an order of magnitude more sites (think schoolhouse roofs)
    Rex> and consequently more handoffs (aka routing table volatility).

Great, but unless you are saying that the EMT is going to use my home
network to get more bits through,  I don't think this is at all in
scope.

The EMT have the organization and manpower and mandate to have a managed
network.  The home network has no manpower, and is seldom organized.
(The more geekier the network, the less organized :-))

---

From: Michael Richardson <[email-masked]>
Date: Sun, 09 Oct 2011 13:43:55 -0400

>>>>> "Chris" == Chris Elliott <[email-masked]> writes:

    >> It's not much of an access point if it doesn't have a second
    >> interface, is it?  If it's out at the pool, and it has no wired
    >> layer2, then it might well have a second radio (or a second
    >> ESSID), to relay.  But, it might also be connected to the wired
    >> network in the pool house.

    Chris> Bridging works fine between 802.11 and 802.1--or another
    Chris> 802.11 link. No routing required.

    Chris> It works for the IETF meeting networks and pretty much how
    Chris> all Enterprise gear is setup.

Chris, I've helped out at the IETF NOC a number of years ago.
I know lots about the things you do to make the IETF network just work, 
mostly when I encounter other networks/conferences where things rarely
work.  

Do you think that the average home user knows how to turn off multicast,
or even why they should?   And, once they do that, do they know why
their service discovery protocols now fail?

Jim Gettys has repeated many times that multicast on wireless occurs at
much lower data rates (1Mb/s on links that otherwise do 100Mb/s).
Others have said that some access points turn multicast into unicast
frames, but I've not experienced this.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 09 Oct 2011 13:46:14 -0400

>>>>> "Chris" == Chris Elliott <[email-masked]> writes:
    Chris> Often you can buy an access point or a wireless router. Many
    Chris> wireless routers have several switched Ethernet ports and a
    Chris> single "WAN" Ethernet port. Just don't use the "WAN" port and
    Chris> you're bridged. And some wireless routers (the Apple Airport

yes, and now you have two DHCP servers.
IPv4 gives us no clues that we should turn off one of them.