Subject: [homenet] Getting ready for Paris

From: Mark Townsley <[email-masked]>
Date: Sat, 3 Mar 2012 07:56:33 +0100

Paris is coming soon, and we want to use the time effectively. Ray  
and I have asked the homearch document design team to identify areas  
in the homenet architecture document that need discussion time to  
finish up by end of next week. My personal thoughts are that two of  
the most important items we need to finish off by the end of this  
next meeting include boundary detection and what routing protocol we  
are going to use. Without these, we are going to have a hard time  
moving forward at all.

Post your thoughts on the list, and if you want specific agenda time  
to talk about these or other pertinent topics, get your requests into  
us (including your ID reference if you have one, and which of the 5  
chartered topic-areas your request most closely aligns with).

It's time to dive back in.

- Mark

---

From: Dave Taht <[email-masked]>
Date: Sat, 3 Mar 2012 10:50:16 -0800

On Fri, Mar 2, 2012 at 10:56 PM, Mark Townsley <[email-masked]> wrote:
>
> Paris is coming soon, and we want to use the time effectively. Ray and I
> have asked the homearch document design team to identify areas in the
> homenet architecture document that need discussion time to finish up by end
> of next week. My personal thoughts are that two of the most important items
> we need to finish off by the end of this next meeting include boundary
> detection and what routing protocol we are going to use. Without these, we
> are going to have a hard time moving forward at all.
>
> Post your thoughts on the list, and if you want specific agenda time to talk
> about these or other pertinent topics, get your requests into us (including
> your ID reference if you have one, and which of the 5 chartered topic-areas
> your request most closely aligns with).

I've been working on 'running code' and not on 'consensus' all that much.
I'm mostly focused on fixing bufferbloat and basic ipv6 stuff and am
tracking the
linux 3.3 effort (which has vastly improved AQM support) closely
within the context
of the cerowrt project. Builds for that are presently available here:

http://huchra.bufferbloat.net/~cero1/3.3/

I'm happy to report that the babel protocol has landed in the quagga-RE tree
giving two mostly interoperable implementations (the original and
quagga itself),
as well as some rdnss support has been added, potentially obsoleting
radvd. Being able
to use quagga on home gateways rather than other daemons finally opens
up the possibility of even trying the oft-proposed-here Xospf alternative, once
I figure out the proper firewall rules.

And in other news dibbler 0.8.2 has more or less working dhcpv6-PD support
in it, although some problems remain.

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 04 Mar 2012 10:15:08 +1300

On 2012-03-03 19:56, Mark Townsley wrote:
> homenet architecture document that need discussion time to finish up by
> end of next week. 

I noticed that there is no section discussing operations and management
as a topic on its own. It seems to me that this is needed, even if what
it says is that the architecture must ensure that manual operations and
management are either not needed at all, or are absolutely minimal,
or are remotely accessible to specialists.

A couple of days ago I had no IP connectivity at home. The conversation
with the ISP help desk responder included her asking me which model
of D-Link I have, and talking me through its menus. Of course I'd
done all that before I called, but it struck me as ridiculous that
any help desk would ask a domestic customer to do that. It will only
be worse for real homenets.

   Brian

> My personal thoughts are that two of the most
> important items we need to finish off by the end of this next meeting
> include boundary detection and what routing protocol we are going to
> use. Without these, we are going to have a hard time moving forward at all.
> 
> Post your thoughts on the list, and if you want specific agenda time to
> talk about these or other pertinent topics, get your requests into us
> (including your ID reference if you have one, and which of the 5

---

From: SM <[email-masked]>
Date: Sat, 03 Mar 2012 20:15:09 -0800

Hi Brian,
>be worse for real homenets.

The alternative is for the help desk to say that the D-Link 
faulty.  The residential customer might be advised to get an 
ISP-approved device.  "The customer may of course also choose to move 
to a new ISP". :-)

I'll +1 a discussion about operations and management.

Regards,
-sm

---

From: David Harrington <[email-masked]>
Date: Sat, 03 Mar 2012 23:58:04 -0500

+1
--
David Harrington
Director, Transport Area
Internet Engineering Task Force (IETF)
[email-masked]
+1-603-828-1401

---

From: Victor Kuarsingh <[email-masked]>
Date: Sun, 04 Mar 2012 14:41:20 -0500

>or are remotely accessible to specialists.

I would fully agree with Brian's comments here.  This is topic often left
out but is important for real network deployments.

>be worse for real homenets.

This is a real issue today and mechanisms to deal with this in a more
effective matter is important.  Having CS reps walk people through config
menus/pages is problematic (since reps will not be able to learn and/or
keep with all the device variants).

Brian's comments do exemplify an issue which will become extremely
problematic in the future when Home Net complexity increases.  Just adding
in IPv6 (to IPv4) connectivity to this mix has highlighted challenges in
traditional troubleshooting methods.  Part of this was due to the added
complexity of IPv6 (since few customers/support reps had experience in
this area) and the other was that troubleshooting tools for IPv6 were not
as readily availble. My comment was not to focus on IPv6 specifically- but
that of new functionality.

I think a discussion (at minimum) would be warranted here to see what
opportunities we have to address this (soon to be) issue.

Regards,

Victor K

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 4 Mar 2012 18:27:45 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Victor Kuarsingh
Sent: Sunday, March 04, 2012 2:41 PM
To: Brian E Carpenter; Mark Townsley
Cc: [email-masked]
Subject: Re: [homenet] Getting ready for Paris

>out but is important for real network deployments.

Agreed.  However, note management interfaces already exist for a CPE
router in a standard such as the DSL TR-064 exists.  Thus the arch folks
should check with such standards bodies and see what is missing and work
jointly to create a uniform management interface for the CPE router.
For now, the arch document may reference some already existing
documents.

Regards,

Hemant

---

From: Michael Richardson <[email-masked]>
Date: Mon, 05 Mar 2012 14:24:41 -0500

>>>>> "Mark" == Mark Townsley <[email-masked]> writes:
    Mark> Paris is coming soon, and we want to use the time
    Mark> effectively. Ray and I have asked the homearch document design
    Mark> team to identify areas in the homenet architecture document
    Mark> that need discussion time to finish up by end of next week. My
    Mark> personal thoughts are that two of the most important items we
    Mark> need to finish off by the end of this next meeting include
    Mark> boundary detection and what routing protocol we are going to
    Mark> use. Without these, we are going to have a hard time moving
    Mark> forward at all.

And after that, how much security is necessary, vs how much is
sufficient.

-- 
]       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: Randy Turner <[email-masked]>
Date: Mon, 5 Mar 2012 13:54:00 -0800

I noticed there was a new homenet-related draft that talks about the "minimum" physical layout required for homenet-related technology

Have we defined a bounding box around the types of home networking technology we are targeting, or a "maximally complicated" layout that homenet will be able to address with solutions?

Thanks!
Randy

On Mar 2, 2012, at 10:56 PM, Mark Townsley wrote:

> 
> Paris is coming soon, and we want to use the time effectively. Ray and I have asked the homearch document design team to identify areas in the homenet architecture document that need discussion time to finish up by end of next week. My personal thoughts are that two of the most important items we need to finish off by the end of this next meeting include boundary detection and what routing protocol we are going to use. Without these, we are going to have a hard time moving forward at all.
> 
> Post your thoughts on the list, and if you want specific agenda time to talk about these or other pertinent topics, get your requests into us (including your ID reference if you have one, and which of the 5 chartered topic-areas your request most closely aligns with).
>

---

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 06 Mar 2012 12:43:21 +0100

> management are either not needed at all, or are absolutely minimal,

Minimal looks like a problem to me.  If the user gets the device, configures
it and then has a problem X months later, he is likely to have forgotten
that he had to change something in the settings in order to make it work.
If he then tries to fix a problem with a "reset to factory defaults", the
device will never work again.

> or are remotely accessible to specialists.

How can this be arranged?  My CPE has remote access to the config i/f but
I obviously don't want this to be open to the world, so I put a password
on it and can fix things even if I'm away from home (assuming that there
is basic connectivity).  I wouldn't mind giving a password to my ISP
in order to have them help me to support it but then the p/w should be
unique.  That creates a problem on their end, as they'd have to maintain
a DB with password of all CPE's of their 1 million customers.  One p/w
for all devices isn't a good idea either.

> be worse for real homenets.

I don't think the average user will actually check the configuration
menus before calling the helpdesk.  Besides that, if you have no
connectivity, what else can one do but check the configuration over the
phone?  My experience with friends and family with computer problems
is that they always claim that "they didn't touch a thing" but
in practice, they often did, so checking the config of the device is
an useful thing to do.

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk(at)uijterwaal.nl
                                          http://www.uijterwaal.nl
                                          Phone: +31.6.55861746
------------------------------------------------------------------------------

There appears to have been a collective retreat from reality that day.
                                 (John Glanfield, on an engineering project)

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Mar 2012 10:13:47 -0500

>>>>> "Henk" == Henk Uijterwaal <[email-masked]> writes:
    Henk> How can this be arranged?  My CPE has remote access to the
    Henk> config i/f but I obviously don't want this to be open to the
    Henk> world, so I put a password on it and can fix things even if
    Henk> I'm away from home (assuming that there is basic
    Henk> connectivity).  I wouldn't mind giving a password to my ISP in

So, we need for the ISP to get read access to the configuration
information and state.   This seems like a job for SNMP read-only with
community string "public".

Some extra security might be that there is a DHCP option/IPv6CP from the
ISP which tells your device the IP address where their queries are
coming from.

    Henk> I don't think the average user will actually check the
    Henk> configuration menus before calling the helpdesk.  Besides
    Henk> that, if you have no connectivity, what else can one do but
    Henk> check the configuration over the phone?  My experience with
    Henk> friends and family with computer problems is that they always
    Henk> claim that "they didn't touch a thing" but in practice, they
    Henk> often did, so checking the config of the device is an useful
    Henk> thing to do.

If the ISP has a backup of the configuration that was working (via the
read-only interface),  and the device can minimally work after a reset
running-config-to-factory-default, then a comparison could occur.

What matters here is that the reset-to-factory-defaults does not destroy
the previously saved configuration, but rather moves it aside, yet
leaves it accessible to SNMP.

(And then there is the other cfg stuff, the one starts with Y, I think,
and netconf too...?)