> > #6: Support for arbitrary topologies
> >
> >  We currently state that homenets should support arbitrary topologies
> >  (SD1).  There have been some comments that this might not be
> realistic.
> >  Should we continue to shoot for that?
> 
> The users will create arbitrary topologies. How can we stop them?

I don't think it should be a question of trying to stop anybody from doing 
anything. It's a question of what do we want to make easy (via 
auto-configuration or minimal configuration like turning something on/off). 

Certainly somebody could put an Ethernet switch between the CE router WAN and 
service provider bridged modem, and also connect a LAN port to that Ethernet 
switch and then connect the rest of the home network off that Ethernet switch. 
We don't have to stop them. We just don't have to make things auto-magically 
work in this case. I, for one, wouldn't even have a clue as to what they were 
trying to do. So how could the homenet elements guess what was wanted? IMO, 
they shouldn't even try.

My recommendation would be to focus first and foremost on topologies that have 
redeeming value. Topologies that users want to have work, because there is 
something very specific that they want to achieve. In some cases, there may be 
more than one topology that would achieve the same purpose. In that case, I 
would suggest that we try to identify the "best" (more intuitive for the user, 
less code involved, less that can go wrong, less guessing what it is the user 
is trying to do, etc.) way to achieve the goal and focus on making that easy 
for the user, rather than trying to make all ways easy.

Any case where it isn't clear what in the world the user is trying to do, we 
shouldn't require the homenet to guess.

Here are just a few of the specific goals users want to achieve, but often run 
in to trouble accomplishing:
1. ISP provides a CE router and provides IPTV service via set-top boxes (STBs) 
connected to that CE router. User doesn't want ISP CE router prying into his 
home network (topology discovery, available services, etc) and wants to put his 
own router between the ISP CE router and his home network, and make sure no 
multicast services bleed through.
2. ISP provides a CE router and provides IPTV service via set-top boxes (STBs) 
connected to that CE router. User has an existing home network setup with an 
existing router, and wants to leave all of that in place. But he does want his 
home network to be able to interact with the STBs (yes to topology discovery, 
available services, multicast, etc.), and get to the Internet.
3. User wants to have Wi-Fi served from the opposite end of the house from the 
ISP CE router. So he uses powerline-Ethernet bridges and plugs a Wi-Fi router 
into a powerline-Ethernet bridge on the other end of the house. He wants 
everything to behave like one big happy network.
4. User's Wi-Fi CE router (from the ISP, with built-in PHY modem to the WAN) 
doesn't support multiple SSIDs, and user wants to set up a special "guest" SSID 
that will let guests get to the Internet, but not the user's home network. So 
the user gets another Wi-Fi router and wants to use it to accomplish this 
separate Guest-net.
5. User's ISP provides just a single IP(v6) address (not so the user can set up 
a home network, but just so the user can connect a single device). User wants 
to set up a home network, through that one device with just a single IPv6 
address (and, no, requiring the ISP to delegate a prefix is not the solution -- 
this is homenet and not ISPnet; the single IPv6 address is a given and the 
question is how to deal with it to let the user do what he wants to do, 
assuming it's not prohibited).

Anyway, that's just a few. I can think of many more. 
And my experience with users is that they're thrilled if there is "a" way to 
make things work, that's simple and reasonably intuitive. They aren't stuck on 
needing all possible ways to work.
Barbara
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to