Subject: [homegate] Next Steps: Workshop & IETF 78 (Feedback Requested)

From: Jason Livingood <[email-masked]>
Date: Mon, 10 May 2010 09:48:59 -0400

We¹ve been discussing next steps as IETF 78 approaches.  It looks likely
that we will submit a request to hold a second, relatively brief BoF at IETF
78.  This is likely to be one hour in length, covering the following topics
(feel free to send feedback):
-  Review of Goals of BoF
-  Review of Draft Charter (at
http://trac.tools.ietf.org/area/tsv/trac/wiki/HOMEGATE)
-  Discussion of Any Concerns from Other SDOs / Potential Overlap
-  Final Discussion of Charter & How/Whether to Proceed with Homegate

This leads us to the next question, which concerns the workshop we¹d
planned.  When we initially scheduled the workshop we believed that other
SDOs had concerns regarding potential overlap with the proposed IETF
homegate effort.  As a result, the workshop was intended to explore what
each of these other SDOs was doing in terms of focus, and to work through
any concerns regarding overlap and so on.  A primary question we have now is
whether such a workshop discussion is still useful.

If the concerns have been assuaged and the interest is now low in the
workshop, no need to hold it.  If we did hold the workshop, none of the
dates were clear winners but here are some of the ones with better indicated
attendance:
- June 22/23 (Western Europe)
- July 13/14 (Eastern U.S.)
- July 14/15 (Eastern U.S.)

Your feedback is requested on the utility of the cross-SDO workshop, as well
as our plan/agenda for a second BoF.

Regards
Jason

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 10 May 2010 08:15:06 -0700

At 9:48 AM -0400 5/10/10, Jason Livingood wrote:
>This leads us to the next question, which concerns the workshop we'd planned.  When we initially scheduled the workshop we believed that other SDOs had concerns regarding potential overlap with the proposed IETF homegate effort.  As a result, the workshop was intended to explore what each of these other SDOs was doing in terms of focus, and to work through any concerns regarding overlap and so on.  A primary question we have now is whether such a workshop discussion is still useful.

For those of us who are not active in those other SDOs, it would be useful to know what concerns *they* have with the formation of this WG. If people in those SDOs could send concerns, unofficially, to the list, we can get a better sense of whether or not a face-to-face meeting, a day-long telecon, or any meeting at all, is needed.

--Paul Hoffman, Director
--VPN Consortium

---

From: Jason Livingood <[email-masked]>
Date: Tue, 11 May 2010 08:58:41 -0400

On 5/10/10 11:15 AM, "Paul Hoffman" <[email-masked]> wrote:
> 
> For those of us who are not active in those other SDOs, it would be useful to
> know what concerns *they* have with the formation of this WG. If people in
> those SDOs could send concerns, unofficially, to the list, we can get a better
> sense of whether or not a face-to-face meeting, a day-long telecon, or any
> meeting at all, is needed.

Agree.  And if we don't see much interest raised on the list, we'll have to
conclude we don't need such a meeting of course.

J

---

From: Mark Baugher <[email-masked]>
Date: Tue, 11 May 2010 06:56:30 -0700

> conclude we don't need such a meeting of course.

It's hard for me to say because I don't recall exactly why we chose to invite SDO representatives in the first place.  The idea made sense to me because homegate has an interface to the home network and the IETF as an organization has little experience in that realm.  As an organization, we know our way around the service provider interface better than network services to home devices.  So a combination of SDOs and vendors like Apple that develop standards for home networks provide can provide needed background information to many of us and their talks should also provide a common frame of reference for their entire group.  That's what I thought the reasons were for their original intent.  True?

Personally, I have heard enough presentations about UPnP, Bonjour, DLNA, IGRS, etc. that I don't have that much interest.  But I am interested in what homegate is going to do differently from some of these other initiatives and where these technologies have a bearing on what homegate is going to do.

Mark

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

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 May 2010 16:04:27 +0200

Mark,

> Personally, I have heard enough presentations about UPnP, Bonjour, DLNA, IGRS, etc. that I don't have that much interest.  But I am interested in what homegate is going to do differently from some…

with my BBF hat on (co-author of TR-124i2) my only concern would be if homegate would specify something which would conflict with that document. of lesser concern would be if homegate spent time specifying overlapping requirements. even though that appears to be a waste of time.

from purely an IPv6 perspective the "IPv6 CE router requirements" draft represents multiple SDO's involvement (CableLabs, BBF, IETF). and can perhaps be looked at as part summary of TR-124i2 / DOCSIS 3.0.

I think it would be easier to relate to homegate if we knew what we wanted it to do.
did we reach any consensus on the 'issues list' we discussed previously?

cheers,
Ole

---

From: Jason Livingood <[email-masked]>
Date: Fri, 14 May 2010 11:38:10 -0400

> did we reach any consensus on the 'issues list' we discussed previously?

What issues list is that?

Here is our current draft charter and objectives.  Is it more clear from
this what we intend?  If there is still uncertainty, please say so and
please be as specific in your feedback as possible.

http://trac.tools.ietf.org/area/tsv/trac/wiki/HOMEGATE

PROPOSED CHARTER - PLEASE REVIEW / UPDATE
Title: Broadband Home Gateway [HomeGate]

Proposed Charter: Access to broadband Internet services use networking
technology of one form or another within the home, small office/home office
(SOHO) or small to medium business (SMB) as the demarcation between the
local network and the Internet. These technologies almost always involve a
single entity - which is not purely a router - called a "home gateway".
This entity connects a local user or users to various LAN services,
providing some basic level of security.  The majority of Internet users
employ home gateways for this purpose.

However, many serious, long-term problems face users of home gateways today.
At the root of many of these problems is the fact that device manufacturers,
and/or the organizations that specify requirements for such devices, are not
certain which IETF standards and best current practices should be supported,
and when/why that support is needed.  As a result of this, millions of
devices are being deployed every year, which do not work with important IETF
protocols, standards, and best practices that are central to the future of
the Internet. 

One of the problems in this area appears to be that home gateway vendors are
unclear which RFCs are important, or current, and why they are important and
in what context they matter. Thus, the primary objective of the group is
document a baseline of requirements derived from "core" RFCs which must be
supported. A secondary objective is to list desired-but-optional, or
"advanced", requirements from the same RFCs as well as other, non-core RFCs.
The context and reasoning behind each document which is included should be
summarized as well, in order to improve comprehension of why a given
document has been included.  These things will help improve compatibilities
with and capabilities for use of the Internet of today.  This will include a
focus in areas such as DNS proxy behavior, congestion mechanisms support,
and security. 

A secondary problem is compatibility with and capability for the use of the
Internet of tomorrow.  New security needs related to DNS are motivating a
move to DNSSEC.  However, many if not most home gateways cannot handle
DNSSEC, which is expected to be a major problem that could significantly
impede the deployment of DNSSEC globally. Support for IPv6 is also lacking
to a great degree and there is no clear understanding of how such devices
should support IPv6.

This working group will not develop new Internet protocols, but may create
different requirements in the context of home gateways. If the Working Group
believes that new protocols are needed, it will refer the problem to the
IESG for further work in existing or new Working Groups.

Proposed Deliverables and Priorities: The Working Group would work to
improve the network experience that a user of a home gateway gets when using
the Internet. This means specifying the requirements from different RFCs
should be supported in home gateways. This will touch on standards such as:
* IPv6
* DNSSEC RFCs and BCPs
* ECN
* RED (or other queue management)
* DNS Proxy BCPs
* Security-Related BCPs
* Other TBD

The group will create a BCP-level document for home gateways that only
support IPv4, and a second BCP-level document for home gateways that only
support both IPv4 and IPv6.

The group shall prioritize work as follows:
1. IPv4-related topics
2. IPv6-related topics
3. DNS-related topics (DNSSEC, DNS Proxies, etc.)
4. ECN-related topics (congestion and queue management)
5. Security-related topics

Contributors: ISPs and home gateway developers / vendors

Who Uses the Work: Home gateway developers / vendors, ISPs

---

From: <[email-masked]>
Date: Tue, 18 May 2010 17:28:12 +0200

Dear Jason,

Dan has asked in this ML if there in an interest to include avalanche restart concerns to the scope of the homegate. In the context of the ongoing PCP spec, we have proposed the use of DHCP as a means to delay sending PCP messages during massive reboot: http://tools.ietf.org/html/draft-bpw-softwire-pcp-dhcp-01#section-3.3.

We think this solution can be generalised and instead of defining a solution per-service/application/protocol, a generic solution can be documented in a single place. 

Based on the previous discussion on that topic, is there any conclusion to include/exclude such topic to the proposed charter?

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Jason Livingood
Envoyé : vendredi 14 mai 2010 17:38
À : Ole Troan
Cc : Paul Hoffman; [email-masked]
Objet : Re: [homegate] Next Steps: Workshop & IETF 78 (Feedback Requested)

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 18 May 2010 17:36:53 +0200

On 18 mei 2010, at 17:28, <[email-masked]> wrote:

> Dan has asked in this ML if there in an interest to include avalanche restart concerns to the scope of the homegate. In the context of the ongoing PCP spec, we have proposed the use of DHCP as a means to delay sending PCP messages during massive reboot

I don't think DHCP is a good choice here. First of all, DHCP isn't a good choice for pretty much anything because there are separate versions for IPv4 and IPv6 and within DHCPv6 there are stateful and stateless variants and DHCPv6 deployment is _far_ from universal.

But more to the point: DHCP uses multicast. Multicast uses and inordinate amount of capacity on wifi networks, and under many circumstances also more than unicast on switched ethernet. There are ways to work around this, but first creating a problem and then solving it seems inelegant compared to not creating it in the first place.

---

From: <[email-masked]>
Date: Tue, 18 May 2010 18:26:39 +0200

Dear Iljitsh,

DHCP is privided here as an example of solution candidate. I won't argue against what you have just said. 

At this stage, what we asked for is to agree (or not) on the the problem to be solved. Is it something of interest of this initiative or not?

Please don't focus on the solution but on the problem to be solved.

Cheers,
Med

________________________________________
De : Iljitsch van Beijnum [[email-masked]]
Date d'envoi : mardi 18 mai 2010 17:36
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Jason Livingood; Reinaldo Penno; [email-masked]
Objet : Re: [homegate] Next Steps: Workshop & IETF 78 (Feedback Requested)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 18 May 2010 18:48:20 +0200

> Please don't focus on the solution but on the problem to be solved.

I think to some degree the problem is unsolvable, as you need to reinitialize a whole bunch of stuff after an outage whether you like it or not.

So I think it's important that mostly vendors but also protocol designers to some degree should focus on making provisioning systems etc high performance and robust so they can handle large numbers of requests without entering in some kind of congestion collapse. We already apply exponential backoffs in many protocols for exactly this reason.

However, there are some things that can be done. For instance, Apple's iPhone (I'm sure many other devices do the same thing, but I just happen to know this example) does an ARP request for the default gateway when wifi connectivity has changed. If there is an ARP reply (possibly after checking some parameters) then the device will continue to use its current DHCP lease, if there is no ARP reply it will initiate a new DHCP request.

A home gateway could do something similar: after an outage, it could ARP or ping the ISP's router and only reinitialize everything if that request fails. Of course this does require that the DHCP server state at the ISP survives a power failure, and the lease times must be sufficiently long.

Another thing that would probably be useful is to make sure that when layer X isn't working, layers X+1 ... X+N aren't trying to reconnect/rediscover, just making things worse.

---

From: Jason Livingood <[email-masked]>
Date: Mon, 31 May 2010 11:23:21 -0400

Based on the feedback from the advising Area Directors and co-chairs of the
continuing homegate effort, we have determined there is insufficient
interest in and content to justify a 2-day face to face meeting prior to
IETF 78.

However we do believe there is value in an abbreviated, virtual meeting
(WebEx, etc.) prior to IETF 78.  To support this we're proposing several
possible dates, and there is a draft agenda below.  Please give us your
feedback on the agenda and please also vote on dates at

As for IETF 78, we have requested a second BoF (not yet approved).  I will
send the draft agenda for the BoF under separate cover.  We received
guidance to make that agenda short and focused.

DRAFT VIRTUAL WORKSHOP TIMES AND AGENDA (and presenters)

Times listed are **UTC** (so adjust to your local time zone)
Duration: 6 Hours (with 2 breaks)
Start Time: 1:00pm GMT, 10:00am EDT, 7:00am PDT
End Time: 7:00pm GMT, 4:00pm EDT, 1:00pm PDT

1300 - 1315     Agenda bashing
1315  1330     Overview of IETF¹s thinking in this space
1330 - 1345     Use cases: ISP-purchased + Subscriber-purchased devices
1345 - 1405     View from HGI - Duncan Bees
1405 - 1425     View from BBF - Heather Kirksey / Barbara Stark  / Ole Tran
1425 - 1445     View from Cablelabs/eRouter - Jean-Francois Mule
1445 - 1455     Break #1
1455 - 1505     View from UPnP Forum - Mark Baugher
1505 - 1525     View from IEEE 802.1 AVB - Michael Johas Teener
1525 - 1645     View from DLNA
1645 - 1700     Break #2
1700 - 1715     View from device vendor 1: Apple
1715 - 1730     View from device vendor 2: Cisco
1730 - 1745     View from device vendor 2: NetGear
1745 - 1845     Discussion of IETF focus, how to proceed
1845 - 1900     Wrap-up / Next Steps

Jason

---

From: Jason Livingood <[email-masked]>
Date: Mon, 31 May 2010 11:46:44 -0400

We have noted the proposed times below.  Please vote via Doodle poll on the
possible dates at:

http://www.doodle.com/6segkyrseasfz5it

Thanks
Jason

---

From: "Stephen [kiwin] PALM" <[email-masked]>
Date: Mon, 31 May 2010 10:20:42 -0700

The doodle poll times seem to be off by an hour.  -kiwin

-- 
Stephen [kiwin] Palm   Ph.D.                          E:  [email-masked]
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]