Subject: [homenet] #6: Support for arbitrary topologies

From: "homenet issue tracker" <[email-masked]>
Date: Wed, 21 Mar 2012 23:37:26 -0000

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

-- 
-------------------+---------------------------------------
 Reporter:  tjc@…  |      Owner:  draft-ietf-homenet-arch@…
     Type:  task   |     Status:  new
 Priority:  major  |  Milestone:
Component:  arch   |    Version:
 Severity:  -      |   Keywords:
-------------------+---------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/homenet/trac/ticket/6>
homenet <http://tools.ietf.org/homenet/>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Mar 2012 11:57:04 +1300

>  Should we continue to shoot for that?

The users will create arbitrary topologies. How can we stop them?

   Brian

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Sat, 24 Mar 2012 19:44:14 +0000

> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 25 Mar 2012 09:04:03 +1300

Barbara,

>>> #6: Support for arbitrary topologies

...
> 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 so…
...
(Much good sense deleted)

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

I agree entirely, and it's clear that somebody (not necessarily vendors)
will need to write a simple guide on ways to connect up your homenet.
What we should perhaps worry about is tools (beyond classical loop
prevention in bridging and routing protocols) to detect broken topologies
and tell the user about them in a meaningful way. In other words,
instead of "support" arbitrary topologies, "diagnose" unsupported
topologies.

    Brian

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Sat, 24 Mar 2012 18:54:18 -0700

IEEE P1905 is one tool that helps in that regard...
http://grouper.ieee.org/groups/1905/1/

regards, kiwin

On 3/24/2012 1:04 PM, Brian E Carpenter wrote:
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

-- 
Stephen [kiwin] Palm   Ph.D.                          E:  [email-masked]
Senior Technical Director                             T: +1-949-926-PALM
Broadcom Broadband Communications Group               F: +1-949-926-7256
Irvine, California                               W: http://www.kiwin.com
Secondary email accounts:  [email-masked]  [email-masked]
[email-masked]  [email-masked]  [email-masked]  [email-masked]

---

From: "Hartog, F.T.H. (Frank) den" <[email-masked]>
Date: Mon, 26 Mar 2012 04:26:20 +0000

And so is HTIP (ITU G.9973) : http://www.itu.int/rec/T-REC-G.9973-201110-P . On performance evaluation of topology discovery protocols, see also Erik Diaz Castellanos et al, IEEE CCNC 2012: http://goo.gl/ldPZj (here applied to the legacy protocols LLTD and LLDP (IEEE 802.1AB) ; not yet to IEEE P1905 or G.9973). HGI is requiring topology discovery in their draft standard "Requirements for home networks service diagnostics", HGI-
RWD016-R3: http://www.homegateway.org/documents/release_3.asp . 

Kind regards, 

Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen [kiwin] PALM
Sent: Sunday, March 25, 2012 3:54 AM
To: Brian E Carpenter
Cc: [email-masked]; [email-masked]; homenet issue tracker; STARK, BARBARA H; [email-masked]
Subject: Re: [homenet] #6: Support for arbitrary topologies

regards, kiwin

On 3/24/2012 1:04 PM, Brian E Carpenter wrote:
> I agree entirely, and it's clear that somebody (not necessarily 
> vendors) will need to write a simple guide on ways to connect up your homenet.
> prevention in bridging and routing protocols) to detect broken 
> topologies and tell the user about them in a meaningful way. In other 
> words, instead of "support" arbitrary topologies, "diagnose" 
> unsupported topologies.
>
>      Brian

Secondary email accounts:  [email-masked]  [email-masked] [email-masked]  [email-masked]  [email-masked]  [email-masked]

_______________________________________________
homenet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/homenet
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer