Subject: Re: [homenet] Homenet Architecture & Interim Meeting

From: Ray Hunter <[email-masked]>
Date: Wed, 21 Sep 2011 22:19:56 +0200

Thanks very much for producing this draft.

I realise the WG is in a hurry, but I think there's some fundamental 
issues to solve here on sharpening up requirements if the architecture 
is going to last more than a couple of years. I really miss a discussion 
on requirements.

I'm probably going to push forward some things you'll say are not 
typical user requirements and will therefore push back. That's healthy, 
and we should be very clear about the problem homenet is trying to 
solve, and what is, and what is not in scope.

If I think of my own house network, I don't think it fits in any of the 
scenarios in the document today in terms of complexity. That's a bit 
scary. I have IPv4 from one provider, IPv6 from another, DMZ's for 
inbound services, multiple firewalls, wireless extenders...... being 
honest, would your home network fit in with any of the architecture 
pictures? Or is this wishful thinking of what you think your parents / 
friends could realistically manage?

Some major trends in home networking have been hidden from view of the 
network providers and network equipment prociders, (and perhaps the IETF 
too) by large scale use of NAT. If you want to get rid of NAT you're 
going to have to address the following IMVHO. The focus has been largely 
on the number of devices (address depletion), but the real challenge is 
likely to be complexity of requirements (IP becomes ubiquitous).

1) I contend that multi-homing is probably going to become the "norm" in 
Europe by 2022, due to The European Electricity and Gas Directive. That 
corresponds at least to picture 4, if not more.

But that picture seems to presume a single isolation LAN to connect two 
ISP providers of equal worth. I think that reachability, and cost, and 
the services provided by the various networks, may be radically 
different. One may be your entertainment ISP. Another your telephony 
ISP. Another your electricity provider ISP. Your car may connect to the 
electricity network ISP to register charging. Your phone may connect to 
4G whilst not at home and then to WiFi whilst you are at home, and to 
hard wired cable when it is connected to its charger. Or perhaps to 
homenet for controlling the lights and the 4G for voice calls....

We should be clear about what (if any) interaction, provider preference 
/ selection, and fall back scenarios will be implemented as part of the 
homenet providing an ISP selection function; or whether the service 
providers should be seen as providing 3 or more logically separate home 
networks, and where the end device itself has to chose the outbound path 
independently of the ISP's and homenet(s) routing.

2) Wireless is exploding. I contend that the single layer LAN in the 
picture is a non-starter. There is almost certainly going to be at least 
two short range radio system technologies in home networks: one wifi and 
one LoWPAN type network for device control. There may be more 
technologies given the rate electronics is moving at the moment e.g. 
NFC, networking via LED lighting. So there may also be a requirement for 
interconnection of multiple ultra-short range networks via a house 
backbone: e.g. lights on top floor pool to form a mesh network, and 
lights in the basement form a mesh network, but the reinforced concrete 
floor partitions the two wireless meshes, so you need a routed 
connection between them. The various radio and lightwave standards are 
unlikely to be L2 bridgeable IMHO. That may add another layer of routing 
to your picture.

3) Virtual machines are exploding. I run 4 VM's on my workstation. With 
the various upcoming application stores and multiple application 
developers running on one system, I could easily imagine that each 
application eventually runs in its own mini-VM, so each IPv6 host 
becomes the equivalent of an old style mainframe with multiple prefixes 
and intra-machine routing. That may add another layer of routing to your 
picture. There may also be virtual firewalls between those VM's, which 
adds another layer.

4) IPv4 NAT allows limitless layers of stacking of networks (for 
outbound connectivity at least) I think stackable devices are going to 
be important. Why buy a whole new device to support a new wireless 
technology or WAN technology, rather than just an adapter?

I submit that a more suitable generic architecture picture for homenet 
would therefore be multiple trees of indeterminate depth of stacked 
devices, with the ISP router forming the root of each tree network and 
IPvs end nodes the leaves. This would obviously have major consequences 
for the requirements of prefix delegation, routing protocol selection 
etc. You can also argue whether these trees should interact in any 
intelligent way, or whether the end nodes should be individually 
multi-homed to several independent trees and thus have to provide any 
intelligence for ISP selection themselves.

Hope this gets the ball rolling, resulting in an architecture with an 
extended lifespan.

regards,
RayH
> Subject:
> [homenet] draft-chown-homenet-arch-00.txt
> From:
> Tim Chown <[email-masked]>
> Date:
> Wed, 21 Sep 2011 13:27:22 +0100
>
> To:
> [email-masked]
>
> Content-Transfer-Encoding:
> quoted-printable
> Precedence:
> list
> MIME-Version:
> 1.0 (Apple Message framework v1244.3)
> References:
> <[email-masked]> 
> <[email-masked]>
> In-Reply-To:
> <[email-masked]>
> Message-ID:
> <EMEW3|507144591d242f9fb36239f554f547a1[email-masked]> 
>
> Content-Type:
> text/plain; charset=us-ascii
> Message:
> 1
>
>
> Hi,
>
> I have been working with Jari, Jason and Ole to produce a new version of the homenet architecture draft. Mark, who produced the first version with Jari, is now of course WG chair and has stepped down as editor of the text.
>
> The structure of the draft remains similar. We have expanded section 2 on IPv6 implications for home networking, added a couple of extra models in section 3, expanded the principle section and also added a considerations section where we discuss certain topics that may (or may not) be deemed in scope for the text.
>
> Feedback is of course welcome, indeed required!
>
> I don't know whether Mark and Ray will call for WG adoption at this stage. The charter targets a WG draft by the end of September, but this is also a document that I hope will have some additional revisions from your feedback before the interim meeting.
>
> There are some acknowledgements to be added; these will be included in the next version.
>
> Tim
>
> On 21 Sep 2011, at 12:37,[email-masked]  wrote:
>
>    
>> >  A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> >  
>> >  	Title           : Home Networking Architecture for IPv6
>> >  	Author(s)       : Jari Arkko
>> >                            Tim Chown
>> >                            Jason Weil
>> >                            Ole Troan
>> >  	Filename        : draft-chown-homenet-arch-00.txt
>> >  	Pages           : 20
>> >  	Date            : 2011-09-21
>> >  
>> >     This text describes the evolving networking technology within small
>> >     &quot;residential home&quot; networks.  The goal of this memo is to define the
>> >     architecture for IPv6-based home networking.  The text highlights the
>> >     impact of IPv6 on home networking, and illustrates some topology
>> >     scenarios.  The architecture shows how standard IPv6 mechanisms and
>> >     addressing can be employed in home networking, lists a number of
>> >     principles that should apply, and outlines the need for specific
>> >     protocol extensions for certain additional functionality.
>> >  
>> >  
>> >  A URL for this Internet-Draft is:
>> >  http://www.ietf.org/internet-drafts/draft-chown-homenet-arch-00.txt
>>      
>
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Sep 2011 23:44:16 +0300

Ray,

Thanks for your feedback! You bring up important points. More inline:

> I realise the WG is in a hurry, but I think there's some fundamental issues to solve here on sharpening up requirements

That's probably a very valid comment.

> if the architecture is going to last more than a couple of years. I really miss a discussion on requirements.
>
> I'm probably going to push forward some things you'll say are not typical user requirements and will therefore push back. That's healthy, and we should be very clear about the problem homenet is trying to solve, and what is, and what is not in scope.

OK

> If I think of my own house network, I don't think it fits in any of the scenarios in the document today in terms of complexity. That's a bit scary. I have IPv4 from one provider, IPv6 from another, DMZ's for inbound services, multiple firewalls, wireless extenders...... being honest, would your home network fit in with any of the architecture pictures? Or is this wishful thinking of what you think your parents / friends could realistically manage?

I don't think your requirements are that uncommon, I have most of those things, too.

Though its not clear to me exactly how that affects the architecture. Wireless extenders are part of L2 that is not usually visible, though the other things are perhaps more visible to l3. Maybe the effects are what we should be talking about in terms of the requirements.

> Some major trends in home networking have been hidden from view of the network providers and network equipment prociders, (and perhaps the IETF too) by large scale use of NAT. If you want to get rid of NAT you're going to have to address the following IMVHO. The focus has been largely on the number of devices (address depletion), but the real challenge is likely to be complexity of requirements (IP becomes ubiquitous).
>
> 1) I contend that multi-homing is probably going to become the "norm" in Europe by 2022, due to The European Electricity and Gas Directive. That corresponds at least to picture 4, if not more.
>
> But that picture seems to presume a single isolation LAN to connect two ISP providers of equal worth. I think that reachability, and cost, and the services provided by the various networks, may be radically different. One may be your entertainment ISP. Another your telephony ISP. Another your electricity provider ISP. Your car may connect to the electricity network ISP to register charging. Your phone may connect to 4G whilst not at home and then to WiFi whilst you are at home, and to hard wired cable when it is connected to its charger. Or perhaps to homenet for controlling the lights and the 4G for voice calls....
>
> We should be clear about what (if any) interaction, provider preference / selection, and fall back scenarios will be implemented as part of the homenet providing an ISP selection function; or whether the service providers should be seen as providing 3 or more logically separate home networks, and where the end device itself has to chose the outbound path independently of the ISP's and homenet(s) routing.

Today's trend is that utility networks are largely independent, parallel networks. That may change, and separate networks may not be the desirable direction. That being said, I'm a bit reluctant to convert the homenet effort into yet another IPv6 multihoming effort. I'm more in the camp that we should document good existing practice for IPv6 home networks, than try to invent lots of new technology. At least on first go.

> 2) Wireless is exploding. I contend that the single layer LAN in the picture is a non-starter. There is almost certainly going to be at least two short range radio system technologies in home networks: one wifi and one LoWPAN type network for device control.

Yes.

> There may be more technologies given the rate electronics is moving at the moment e.g. NFC, networking via LED lighting. 

Yep.

> So there may also be a requirement for interconnection of multiple ultra-short range networks via a house backbone: e.g. lights on top floor pool to form a mesh network, and lights in the basement form a mesh network, but the reinforced concrete floor partitions the two wireless meshes, so you need a routed connection between them.

I think we do include that already. Its part of being able to provide a routed, multi-subnet network. Precisely for these reasons. (But if you are arguing that we should all use some form of ad hoc routing technology in the entire network, I might disagree because I don't believe those have been shown sufficient deployment experience in the general environment t obe recommended at this time. IMHO, of course.)

> The various radio and lightwave standards are unlikely to be L2 bridgeable IMHO. That may add another layer of routing to your picture.

I agree, but I think you may be reading too much into the picture. Lack of ability to do L2 bridging is the primary reason for having multiple subnets.

>
> 3) Virtual machines are exploding. I run 4 VM's on my workstation. With the various upcoming application stores and multiple application developers running on one system, I could easily imagine that each application eventually runs in its own mini-VM, so each IPv6 host becomes the equivalent of an old style mainframe with multiple prefixes and intra-machine routing. That may add another layer of routing to your picture. There may also be virtual firewalls between those VM's, which adds another layer.

Yep. I have that in my network, too :-) But the question is, what does it imply in terms of requirements? It at least implies that we need to support many devices, and probably even more reason to allow for additional subnets (e.g., to allow one set of virtual machines exist in their own subnet inside a physical device).

> 4) IPv4 NAT allows limitless layers of stacking of networks (for outbound connectivity at least) I think stackable devices are going to be important. Why buy a whole new device to support a new wireless technology or WAN technology, rather than just an adapter?

OK, but...

> I submit that a more suitable generic architecture picture for homenet would therefore be multiple trees of indeterminate depth of stacked devices, with the ISP router forming the root of each tree network and IPvs end nodes the leaves. This would obviously have major consequences for the requirements of prefix delegation, routing protocol selection etc. You can also argue whether these trees should interact in any intelligent way, or whether the end nodes should be individually multi-homed to several independent trees and thus have to provide any intelligence for ISP selection themselves.

... and I think we definitely agree that any address allocation, discovery, or routing scheme should work at least with trees of indeterminate depth (or perhaps even with more complex topologies). As noted above, I'm a bit hesitant on multihoming though.

>
> Hope this gets the ball rolling, resulting in an architecture with an extended lifespan.

I think it does set the ambition level correctly. Thank you.

Jari

---

From: Jim Gettys <[email-masked]>
Date: Wed, 21 Sep 2011 16:49:37 -0400

On 09/21/2011 04:19 PM, Ray Hunter wrote:
> is going to last more than a couple of years. I really miss a
> discussion on requirements.
>
> typical user requirements and will therefore push back. That's
> healthy, and we should be very clear about the problem homenet is
> trying to solve, and what is, and what is not in scope.
>
> If I think of my own house network, I don't think it fits in any of
> the scenarios in the document today in terms of complexity. That's a
> bit scary. I have IPv4 from one provider, IPv6 from another, DMZ's for
> network providers and network equipment prociders, (and perhaps the
> IETF too) by large scale use of NAT. If you want to get rid of NAT
> you're going to have to address the following IMVHO. The focus has
> been largely on the number of devices (address depletion), but the
> real challenge is likely to be complexity of requirements (IP becomes
> ubiquitous).
>
> 1) I contend that multi-homing is probably going to become the "norm"
> in Europe by 2022, due to The European Electricity and Gas Directive.
> That corresponds at least to picture 4, if not more.
>
> But that picture seems to presume a single isolation LAN to connect
> two ISP providers of equal worth. I think that reachability, and cost,
> and the services provided by the various networks, may be radically
> ISP. Another your electricity provider ISP. Your car may connect to
> the electricity network ISP to register charging. Your phone may
> connect to 4G whilst not at home and then to WiFi whilst you are at
> home, and to hard wired cable when it is connected to its charger. Or
> perhaps to homenet for controlling the lights and the 4G for voice
> calls....
>
> We should be clear about what (if any) interaction, provider
> preference / selection, and fall back scenarios will be implemented as
> part of the homenet providing an ISP selection function; or whether
> the service providers should be seen as providing 3 or more logically
> separate home networks, and where the end device itself has to chose
> the outbound path independently of the ISP's and homenet(s) routing.
>
> picture is a non-starter. There is almost certainly going to be at
> least two short range radio system technologies in home networks: one
> wifi and one LoWPAN type network for device control. There may be more
> NFC, networking via LED lighting. So there may also be a requirement
> for interconnection of multiple ultra-short range networks via a house
> lights in the basement form a mesh network, but the reinforced
> concrete floor partitions the two wireless meshes, so you need a
> routed connection between them. The various radio and lightwave
> standards are unlikely to be L2 bridgeable IMHO. That may add another
> layer of routing to your picture.

Bridging a gigabit ethernet and even today's wireless is asking for
tremendous trouble; a tiny amount of multicast on ethernet can already
ruin your whole day on wireless (since it is transmitted at 1Mbit).  And
some of the future wireless technology puts the disparity of bandwidth
even higher.

Many home routers now have 2 radios (2.4 and 5ghz) and guest networks
are also the "norm".  So we're already at 6 networks in a single home
router box (wan, local ethernet, [email-masked], 802.11@5, [email-masked],
802.11guest@5ghz), and need also a DMZ network, much less dealing with
VPN's, and more complex home network topologiesk.

This message brought to you via a home router which routes, not bridges,
these networks.  More about this topic next week....
                    - Jim

>
> 3) Virtual machines are exploding. I run 4 VM's on my workstation.
> With the various upcoming application stores and multiple application
> becomes the equivalent of an old style mainframe with multiple
> prefixes and intra-machine routing. That may add another layer of
> routing to your picture. There may also be virtual firewalls between
> those VM's, which adds another layer.
>
> IPvs end nodes the leaves. This would obviously have major
> consequences for the requirements of prefix delegation, routing
> protocol selection etc. You can also argue whether these trees should
> interact in any intelligent way, or whether the end nodes should be
> individually multi-homed to several independent trees and thus have to
> provide any intelligence for ISP selection themselves.
>
>> On 21 Sep 2011, at 12:37, [email-masked] wrote:
>>
>>   
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Ray Hunter <[email-masked]>
Date: Thu, 22 Sep 2011 12:06:26 +0200

Unfortunately I cannot attend the Homenet meeting in person, so I'm 
going to have to provide my input up front. Excuse me if this seems a 
bit of a one sided brain dump. Following up on your points, and 
translating one stage further from technology trend to principles.....

I think you've got a good list of principles already.

If I compare the list of principles and constraints I would generate for 
my existing home network with the list in the ID I can see some common 
ground and some differences:

1) physical limitations of underlying media meaning technology 
translation across very diverse types of media => routing between 
segments where there is more than one IPv6 segment in the Homenet.
[already mentioned explicitly]

2) physical constraints of buildings and range of wireless 
technologies=> distributed functions: possibly no single central 
"Homenet router" + routing between Homenet boxes, open inter-box 
protocols + Homenet acting as a backbone to interconnect radio clouds 
across different media (LoWPAN - cabled Ethernet - LoWPAN or cabled 
Ethernet - WiFi - cabled Ethernet)
[not yet mentioned explicitly, runs contrary to requirement for simplicity]

3) VM is a single machine performing multiple functions => greater depth 
of networks + need to standardize the abstraction of logical Homenet 
functions to support a distributed implementation (prefix delegation, 
topology detection, default outbound route determination, return path 
route selection, packet forwarding, firewall, administration, name 
resolution, neighbor validation,  link security, outbound address/ISP 
selection .... ) + need to incorporate logical Homenet functions into VM 
products
[not yet mentioned explicitly, runs contrary to requirement for 
simplicity and single Homenet box/segments]

4) Plug and play management by non-expert users = sensible defaults and 
auto configuration where possible + need to automatically or manually 
identify and communicate administrative boundaries
[not yet mentioned explicitly]

5) Stacked devices leading to indeterminate depth of Homenet 
architecture: requirement for a function in Homenet to automatically 
produce at least a logical tree topology (c.f. spanning tree) and to 
perform cascaded prefix delegation and default route determination. I 
really miss the requirement for indeterminate depth of cascading in this 
draft. This is a key feature that NATv4 provides today. I also miss 
whether just a tree topology or a full mesh is desirable / achievable, 
bearing in mind that if multiple radio networks are interconnected by 
say hard wired Ethernet they may also still interact weakly via the 
radio link => standardized inter-box routing protocol. I think deciding 
what to support from this requirement (or not) is going to be a key 
driver for the final cost and complexity of devices.
[not yet mentioned explicitly: the scenarios in the ID would seem to 
imply limited depth of cascading]

6) Guest LANs DMZ etc. and admin boundaries = requirement of a function 
to detect upstream and downstream neighbors and to activate / deactivate 
other functions based on the position in the topology, either manually 
or automatically.
[already mentioned explicitly]

7) Depending on whether you want to include / exclude multi-homing in 
Homenet => push multihoming to end node requirements + potential network 
to end node signalling; or push multihoming into routers => possible 
need for a NAT66 type functions
[not yet explicitly mentioned where the ISP selection function of 
multi-homing should reside: in the Homenet network or the end node]

8) Non expert buyers => need to be clear on what functions are supported 
in which type of device => capability matrix / Homenet labeling c.f. HD 
Ready, Full HD.
[not yet mentioned explicitly]

9) Roll out this year => no new protocols + Homenet architecture updates 
via futures version control with backwards compatibility => Homenet v1 
v2 v3 v4?
[not yet mentioned explicitly]

These may seem like platitudes but I think they will be useful to 
reference in later discussions when evaluating alternatives, especially 
because there are definitely going to be conflicting requirements. I can 
imagine the discussion in the workshop may become quite heated between 
those wanting functionality versus those wanting to keep costs down. I 
personally think tomorrow's Homenet is going to have a lot more in 
common with today's SME site network than a stand alone flat LAN. Others 
may disagree.

Further, I suspect you'll struggle to get consensus on specifying 
individual protocols matched to logical Homenet functions like 
recommending 
http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-01 for 
network to end node signalling for ISP selection. Maybe that's a 
different draft.  And I'll think you'll really struggle with prefix 
delegation and name resolution in a tree of cascaded devices of 
indeterminate depth whilst still avoiding creating a need for a new or 
altered protocol, but I wish you luck.

regards,
RayH

Jari Arkko wrote:
>> issues to solve here on sharpening up requirements 
>
>> if the architecture is going to last more than a couple of years. I 
>> really miss a discussion on requirements.
>>
>> healthy, and we should be very clear about the problem Homenet is 
>> bit scary. I have IPv4 from one provider, IPv6 from another, DMZ's 
>> for inbound services, multiple firewalls, wireless extenders...... 
>> being honest, would your home network fit in with any of the 
>> architecture pictures? Or is this wishful thinking of what you think 
>> your parents / friends could realistically manage? 
>
> Though its not clear to me exactly how that affects the architecture. 
> Wireless extenders are part of L2 that is not usually visible, though 
> the other things are perhaps more visible to l3. Maybe the effects are 
> what we should be talking about in terms of the requirements.
>
>
>> Some major trends in home networking have been hidden from view of 
>> the network providers and network equipment prociders, (and perhaps 
>> the IETF too) by large scale use of NAT. If you want to get rid of 
>> NAT you're going to have to address the following IMVHO. The focus 
>> has been largely on the number of devices (address depletion), but 
>> the real challenge is likely to be complexity of requirements (IP 
>> becomes ubiquitous).
>>
>> two ISP providers of equal worth. I think that reachability, and 
>> cost, and the services provided by the various networks, may be 
>> radically different. One may be your entertainment ISP. Another your 
>> telephony ISP. Another your electricity provider ISP. Your car may 
>> connect to the electricity network ISP to register charging. Your 
>> phone may connect to 4G whilst not at home and then to WiFi whilst 
>> you are at home, and to hard wired cable when it is connected to its 
>> charger. Or perhaps to Homenet for controlling the lights and the 4G 
>> for voice calls....
>>
>> preference / selection, and fall back scenarios will be implemented 
>> as part of the Homenet providing an ISP selection function; or 
>> whether the service providers should be seen as providing 3 or more 
>> logically separate home networks, and where the end device itself has 
>> to chose the outbound path independently of the ISP's and Homenet(s) 
>> routing. 
>
> Today's trend is that utility networks are largely independent, 
> parallel networks. That may change, and separate networks may not be 
> the desirable direction. That being said, I'm a bit reluctant to 
> convert the Homenet effort into yet another IPv6 multihoming effort. 
> I'm more in the camp that we should document good existing practice 
> for IPv6 home networks, than try to invent lots of new technology. At 
> least on first go.
>
>> wifi and one LoWPAN type network for device control. 
>
> Yes.
>
>> There may be more technologies given the rate electronics is moving 
>> at the moment e.g. NFC, networking via LED lighting. 
>
> Yep.
>
>> So there may also be a requirement for interconnection of multiple 
>> ultra-short range networks via a house backbone: e.g. lights on top 
>> floor pool to form a mesh network, and lights in the basement form a 
>> mesh network, but the reinforced concrete floor partitions the two 
>> wireless meshes, so you need a routed connection between them. 
>
> I think we do include that already. Its part of being able to provide 
> a routed, multi-subnet network. Precisely for these reasons. (But if 
> you are arguing that we should all use some form of ad hoc routing 
> technology in the entire network, I might disagree because I don't 
> believe those have been shown sufficient deployment experience in the 
> general environment t obe recommended at this time. IMHO, of course.)
>
>> The various radio and lightwave standards are unlikely to be L2 
>> bridgeable IMHO. That may add another layer of routing to your picture. 
>
> I agree, but I think you may be reading too much into the picture. 
> Lack of ability to do L2 bridging is the primary reason for having 
> multiple subnets.
>
> Yep. I have that in my network, too :-) But the question is, what does 
> it imply in terms of requirements? It at least implies that we need to 
> support many devices, and probably even more reason to allow for 
> additional subnets (e.g., to allow one set of virtual machines exist 
> in their own subnet inside a physical device).
>
>> outbound connectivity at least) I think stackable devices are going 
>> to be important. Why buy a whole new device to support a new wireless 
>> I submit that a more suitable generic architecture picture for 
>> Homenet would therefore be multiple trees of indeterminate depth of 
>> stacked devices, with the ISP router forming the root of each tree 
>> network and IPvs end nodes the leaves. This would obviously have 
>> major consequences for the requirements of prefix delegation, routing 
>> individually multi-homed to several independent trees and thus have 
>> to provide any intelligence for ISP selection themselves. 
>
> ... and I think we definitely agree that any address allocation, 
> discovery, or routing scheme should work at least with trees of 
> indeterminate depth (or perhaps even with more complex topologies). As 
> noted above, I'm a bit hesitant on multihoming though.
>