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:
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
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
