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: 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: Randy Turner <[email-masked]>
Date: Mon, 3 Oct 2011 08:58:37 -0700

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

---

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:

> 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: 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: 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: Jeff Tantsura <[email-masked]>
Date: Mon, 3 Oct 2011 14:10:58 -0400

+1 - we know LS protocols rather well to not to use them

Today's in-home devices have more CPU horsepower/memory than an OSPF
router 10 years ago, there's also no reason to reinvent the wheel, perhaps
we should separate 2012 goals from long term ones.
Having "dumb" end nodes + border router in-between in the beginning and
e2e native communication as the end model worked rather well over the
years.

Cheers,
Jeff 

On 10/3/11 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.
>
>> 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
>> 
>> 
>>>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
>>> 
>>> 
>>> 
>>> >
>>> >>
>>> >> 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.

---

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

---

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

> in the home...this seems like using a sledgehammer to kill an ant.  How many
> 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
> > >>
> > >>
> > >>
> > >> >
> > >> >>
> 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

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: Michael Richardson <[email-masked]>
Date: Mon, 03 Oct 2011 21:26:02 -0400

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

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

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