Re: [homegate] [fun] status of the homenet effort
Ralph Droms <rdroms.ietf@gmail.com> Fri, 01 July 2011 14:26 UTC
Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: homegate@ietfa.amsl.com
Delivered-To: homegate@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B24421F84FA; Fri, 1 Jul 2011 07:26:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.132
X-Spam-Level:
X-Spam-Status: No, score=-103.132 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXBsrowEFGIh; Fri, 1 Jul 2011 07:26:31 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50EB621F84F9; Fri, 1 Jul 2011 07:26:24 -0700 (PDT)
Received: by pzk5 with SMTP id 5so3894207pzk.31 for <multiple recipients>; Fri, 01 Jul 2011 07:26:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=0piBSHXuBrcJLTFiQobDEzUVldrU7/vidaH69GGMVUA=; b=YYURJTV6h1KTmWHUcNlHio2A5LrwyNtMuAMYvFd0plh630vYrxpI4nqMpoyU5FXy4K 7P4Guut+92ZH7QP+Ob2LVWmcH+vMqZZ3wd/wY8Z+M8IsE6NW7RmM9QhvSzKbcFBi1InU 9kaFP9pjjomyK0zOdhEh++PdzrG0OC8CSW6WE=
Received: by 10.142.48.10 with SMTP id v10mr1461479wfv.185.1309530383831; Fri, 01 Jul 2011 07:26:23 -0700 (PDT)
Received: from [10.21.108.95] (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id m7sm1999537pbk.38.2011.07.01.07.26.20 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 07:26:22 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <CA3341C2.4C55%jason.weil@twcable.com>
Date: Fri, 01 Jul 2011 10:26:13 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <5A77C1B3-59BF-4B23-ACD0-A5C3CD9E954D@gmail.com>
References: <CA3341C2.4C55%jason.weil@twcable.com>
To: "Weil, Jason" <jason.weil@twcable.com>
X-Mailer: Apple Mail (2.1084)
Cc: "fun@ietf.org" <fun@ietf.org>, "homegate@ietf.org" <homegate@ietf.org>, "JP Vasseur (jvasseur)" <jvasseur@cisco.com>
Subject: Re: [homegate] [fun] status of the homenet effort
X-BeenThere: homegate@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Broadband Home Gateway Discussion <homegate.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homegate>, <mailto:homegate-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homegate>
List-Post: <mailto:homegate@ietf.org>
List-Help: <mailto:homegate-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homegate>, <mailto:homegate-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jul 2011 14:26:36 -0000
On Jul 1, 2011, at 9:32 AM 7/1/11, Weil, Jason wrote: > > > On 7/1/11 4:06 AM, "Mark Townsley" <mark@townsley.net> wrote: > >> >> On Jul 1, 2011, at 7:27 AM, JP Vasseur (jvasseur) wrote: >> >>> I also think that this deals with an important topic and the list of >>> items listed on the proposed charter are quite relevant. I'm just not >>> entirely clear on the "routing component": are you referring to: >>> * A requirement document for Routing in the home? >> >> At least a section within a home architecture document. >> >>> * A recommendation for a specific routing protocol ? > > [JW] I see a guidelines/analysis for link-state vs. distance-vector > routing protocols in a multi-segment home network as being useful. In my opinion, operation without active admin intervention is more important than the particular technology. - Ralph > >> >>> * A framework before the specification of a new routing protocol ? > > [JW] A framework or justification statement for a new lightweight routing > protocol would be useful as well. A source/dest aware protocol has been > proposed as a possible solution for the multi-homed home network for > example. > >> >> The charter says: >> >> "For automatic routing, it is expected that existing >> routing protocols can be used as is, however, a new mechanism may be >> needed in order to turn a selected protocol on by default." >> >> - Mark >> >> >>> I'm clearly not expressing an opinion, just a question. >>> Thanks. >>> JP. >>> >>> JP Vasseur >>> Cisco Fellow >>> >>> Sent from Blackberry >>> >>> ----- Original Message ----- >>> From: Mark Townsley [mailto:mark@townsley.net] >>> Sent: Thursday, June 30, 2011 11:36 AM >>> To: Weil, Jason <jason.weil@twcable.com> >>> Cc: fun@ietf.org <fun@ietf.org>; homegate@ietf.org <homegate@ietf.org> >>> Subject: Re: [fun] status of the homenet effort >>> >>> >>> Thank you for the feedback, keep it coming. >>> >>> On Jun 30, 2011, at 4:14 PM, Weil, Jason wrote: >>> >>>> Mark, Raplh, Jari, et all, >>>> >>>> I really appreciate the change in charter and direction for this >>>> proposed >>>> WG and the interest to keep it going. I believe it sets a path that is >>>> scoped narrow enough to provide a workplace for achievable results. >>>> >>>> As a provider working on writing, testing and implementing IPv6 CPE, I >>>> can >>>> relate firsthand that getting basic IPv6 functionality working in the >>>> home >>>> network is no simple feat and is still a work in progress. Don't get me >>>> wrong, basic functionality is there just not baked. What seems very >>>> straightforward in theory typically fails in a multitude of corner >>>> cases >>>> ie reality. And just to clarify I am referring to a single /64 subnet >>>> topology with no routing. >>>> >>>> If we can stay focussed on solving just the basics for the five areas >>>> included, I believe it will be helpful. The other recommendation would >>>> be >>>> to work as expeditiously as possible. Providers in the process of >>>> deploying IPv6 now are already deep into this analysis and development >>>> with their vendors. If we wait too long then these topics will be >>>> solved >>>> with interoperability a possible casualty. >>>> >>>> FWIW, I would also add that the five topics in the charter are also >>>> listed >>>> in order >>>> Of priority at least for me. >>>> >>>> >>>> Thanks, >>>> >>>> Jason >>>> >>>> >>>> On 6/29/11 5:46 AM, "Mark Townsley" <mark@townsley.net> wrote: >>>> >>>>> >>>>> All, >>>>> >>>>> Apologies for double-posting if there are folks that are subscribed to >>>>> homegate@ietf.org and fun@ietf.org. I'm hoping soon that someone will >>>>> finally create homenet@ietf.org and consolidate the membership >>>>> accordingly. >>>>> >>>>> In the charter proposal below, I think you will see a lot of >>>>> similarity >>>>> with the consensus we achieved on the homegate list last year. Jari >>>>> has >>>>> taken that, feedback from the IESG, IAB, members of the >>>>> IP-Directorate, >>>>> v6ops chairs, etc. and shaped it towards something more focused on the >>>>> Internet (and Routing) area, as well as IPv6. I believe he and Ralph >>>>> both >>>>> have a great deal of confidence that this is something that is very >>>>> important to the industry, and that the IETF has a critical role to >>>>> play. >>>>> >>>>> So, make no mistake, whether we end up as a WG or a BoF between now >>>>> and >>>>> Quebec, "we're back" - please send comments, and make your travel or >>>>> remote-attendance plans accordingly if you want to participate. >>>>> >>>>> Jari has asked me to co-chair the session in Quebec. As such, I'd >>>>> like to >>>>> take requests for presentation time now. Jari and I will likely begin >>>>> the >>>>> session with a scoping overview, as well as a first cut at an >>>>> architecture framework, but there should be some time for a few other >>>>> items. When submitting your request, please identify which of the 5 >>>>> areas >>>>> below you think your work applies to as well as the internet-draft, of >>>>> course. >>>>> >>>>> Thanks, and see you on the list and in Quebec. >>>>> >>>>> - Mark >>>>> >>>>> >>>>> On Jun 29, 2011, at 10:35 AM, Jari Arkko wrote: >>>>> >>>>>> I wanted to provide an update of the situation with this working >>>>>> group >>>>>> proposal. >>>>>> >>>>>> HOMENET is a new working group proposal, a variation of the >>>>>> HOMEGATE/HOMENET theme that we discussed last year, but this time >>>>>> looking at it from a different angle. The old effort was mostly >>>>>> focused >>>>>> about what home gateways should do: forwarding, transport, and DNS >>>>>> proxying issues. The new effort is about home networks themselves, in >>>>>> particular what kind of network architecture and configuration is >>>>>> necessary to support IPv6-based home networks. We view IPv4-based >>>>>> home >>>>>> networks as "done" at this time (or perhaps as "cannot be changed >>>>>> anyway"). >>>>>> >>>>>> I have been discussing this effort in the background for the last >>>>>> couple of month with Mark Townsley and others, and more publicly >>>>>> since >>>>>> early June. The proposal has been brought to the IESG, IAB and some >>>>>> directorates for discussion, and we've been going back and forth >>>>>> whether >>>>>> this is ready to become a working group or needs to be run as a BOF >>>>>> in >>>>>> Quebec City. The current plan is that the working group proposal >>>>>> goes to >>>>>> IETF-wide review this week, and if the feedback from the community, >>>>>> IAB, >>>>>> and the IESG is positive, we will create the working group just in >>>>>> time >>>>>> for the IETF. Otherwise, the slot reserved in the agenda for the >>>>>> meeting >>>>>> will be used to run the proposal as a BOF. >>>>>> >>>>>> In any case, I would like to solicit discussion on this topic, and >>>>>> perhaps some early drafts as well. Please comment on the charter at >>>>>> least. >>>>>> >>>>>> Note that the new proposal was called FUN at the time that we created >>>>>> the list. It has now been renamed back to HOMENET to be more >>>>>> descriptive. The list will be renamed soon as well (current >>>>>> subscribers >>>>>> will stay). >>>>>> >>>>>> This is the most recent version of the charter we should discuss: >>>>>> >>>>>> Home Networks (homenet) >>>>>> ----------------------------------- >>>>>> >>>>>> Current Status: Proposed >>>>>> Last Edit: Wednesday, June 29th, 2011 >>>>>> >>>>>> Chairs: >>>>>> TBD >>>>>> >>>>>> Internet Area Directors: >>>>>> Ralph Droms <rdroms.ietf@gmail.com> >>>>>> Jari Arkko <jari.arkko@piuha.net> >>>>>> >>>>>> Internet Area Advisor: >>>>>> Jari Arkko <jari.arkko@piuha.net> >>>>>> >>>>>> Routing Area Technical Advisor: >>>>>> TBD >>>>>> >>>>>> Security Area Technical Advisor: >>>>>> TBD >>>>>> >>>>>> Mailing Lists: >>>>>> General Discussion: fun@ietf.org >>>>>> To Subscribe: https://www.ietf.org/mailman/listinfo/fun >>>>>> Archive: http://www.ietf.org/mail-archive/web/fun >>>>>> >>>>>> Description of Working Group: >>>>>> >>>>>> This working group focuses on the evolving networking technology >>>>>> within and among relatively small ³residential home² networks. For >>>>>> example, an obvious trend in home networking is the proliferation of >>>>>> networking technology in an increasingly broad range and number of >>>>>> devices. This evolution in scale and diversity sets some requirements >>>>>> on IETF protocols. Some of the relevant trends include: >>>>>> >>>>>> o Multiple segments: While less complex L3-toplogies involving as few >>>>>> subnets as possible are preferred in home networks for a variety of >>>>>> reasons including simpler management and service discovery, the >>>>>> introduction of more than one subnet into a home network is enough >>>>>> to add complexity that needs to be addressed, and multiple >>>>>> dedicated segments are necessary for some cases. For instance, a >>>>>> common feature in modern home routers in the ability to support >>>>>> both guest and private network segments. Also, link layer >>>>>> networking technology is poised to become more heterogeneous, as >>>>>> networks begin to employ both traditional Ethernet technology and >>>>>> link layers designed for low-powered sensor networks. Finally, >>>>>> similar needs for segmentation may occur in other cases, such as >>>>>> separating building control or corporate extensions from the >>>>>> Internet access network. Different segments may be associated with >>>>>> subnets that have different routing and security policies. >>>>>> >>>>>> o Service providers are deploying IPv6, and support for IPv6 is >>>>>> increasingly available in home gateway devices. While IPv6 resembles >>>>>> IPv4 in many ways, it changes address allocation principles and >>>>>> allows >>>>>> direct IP addressability and routing to devices in the home from the >>>>>> Internet. This is a promising area in IPv6 that has proved >>>>>> challenging >>>>>> in IPv4 with the proliferation of NAT. >>>>>> >>>>>> o End-to-end communication is both an opportunity and a concern as it >>>>>> enables new applications but also exposes nodes in the internal >>>>>> networks to receipt of unwanted traffic from the Internet. Firewalls >>>>>> that restrict incoming connections may be used to prevent exposure, >>>>>> however, this reduces the efficacy of end-to-end connectivity that >>>>>> IPv6 has the potential to restore. >>>>>> >>>>>> Home networks need to provide the tools to handle these situations in >>>>>> a manner accessible to all users of home networks. Manual >>>>>> configuration is rarely, if at all, possible. The purpose of this >>>>>> working group is to focus on this evolution, in particular as it >>>>>> addresses the introduction of IPv6, by developing an architecture >>>>>> addressing this full scope of requirements: >>>>>> >>>>>> o prefix configuration for routers >>>>>> o managing routing >>>>>> o name resolution >>>>>> o service discovery >>>>>> o network security >>>>>> >>>>>> The task of the group is to produce an architecture document that >>>>>> outlines how to construct home networks involving multiple routers >>>>>> and >>>>>> subnets. This document is expected to apply the IPv6 addressing >>>>>> architecture, prefix delegation, global and ULA addresses, source >>>>>> address selection rules and other existing components of the IPv6 >>>>>> architecture. The architecture document should drive what protocols >>>>>> changes, if any, are necessary. Specific protocol work described >>>>>> below >>>>>> is expected to be within the scope of the working group one the >>>>>> architecture work is complete. However, the group is required to >>>>>> review its charter and milestones with the IESG and IETF community >>>>>> before submitting documents that make protocol changes. It is >>>>>> expected >>>>>> that the group has to discuss some of the below solutions, however, >>>>>> in >>>>>> order to complete the architecture work. >>>>>> >>>>>> The group will apply existing protocols to handle the five >>>>>> requirements above. For prefix configuration, existing protocols are >>>>>> likely sufficient, and at worst may need some small enhancements, >>>>>> such >>>>>> as new options. For automatic routing, it is expected that existing >>>>>> routing protocols can be used as is, however, a new mechanism may be >>>>>> needed in order to turn a selected protocol on by default. For name >>>>>> resolution and service discovery, extensions to existing >>>>>> multicast-based name resolution protocols are needed to enable them >>>>>> to >>>>>> work across subnets. >>>>>> >>>>>> For network security, the group shall document the concept of >>>>>> "advanced security" as a further development of "simple security" >>>>>> from >>>>>> RFC 6092. The main goal of this work is to enable a security policy >>>>>> that adapts to IPv6 threats as they emerge, taking into account not >>>>>> only traffic from the Internet at large, but within and leaving the >>>>>> home network itself. >>>>>> >>>>>> It is expected that the working group will define a set of protocol >>>>>> specifications to accomplish the five requirements from >>>>>> above. However, it is not in the scope of the working group to define >>>>>> entirely new routing protocols or address allocation protocols. As >>>>>> noted, additional options or other small extensions may be necessary >>>>>> to use the existing protocols in these new configuration tasks. The >>>>>> working group shall also not make any changes to IPv6 protocols or >>>>>> addressing architecture. Prefix configuration, routing, and security >>>>>> related work shall not cause any changes that are not backwards >>>>>> compatible to existing IPv6 hosts. There may be host visible changes >>>>>> in the work on naming and discovery protocols, however. In its >>>>>> design, >>>>>> the working group shall also consider security aspects and the impact >>>>>> on manageability. The main focus of the working group is home >>>>>> networks, but the group's results may also find applications in other >>>>>> small networks. >>>>>> >>>>>> The working group will liaise with the relevant IETF working >>>>>> groups. In particular, the group should work closely with the V6OPS >>>>>> working group, review any use or extension of DHCP with the DHC >>>>>> working group, and work with additional DNS requirements with the >>>>>> DNSEXT and DNSOP working groups. If it turns out that additional >>>>>> options are needed for a routing protocol, they will be developed in >>>>>> the appropriate Routing Area working group, with the HOMENET working >>>>>> group providing the architecture and requirements for such >>>>>> enhancements. The working group will also liase with external >>>>>> standards bodies where it is expected that there are normative >>>>>> dependencies between the specifications of the two bodies. >>>>>> It is expected that in the architecture definition stage liaising >>>>>> with the Broadband Forum, DLNA, and UPnP Forum is necessary. >>>>>> >>>>>> Milestones: >>>>>> >>>>>> Jul 2011 Formation of the working group >>>>>> Sep 2011 First WG draft on the architecture >>>>>> Dec 2011 Submission of the architecture draft to the IESG as >>>>>> Informational RFC >>>>>> Dec 2011 Charter re-evaluation based on the architecture work >>>>>> Dec 2011 First WG draft on prefix configuration >>>>>> Dec 2011 First WG draft on routing >>>>>> Jan 2012 First WG draft on name resolution >>>>>> Feb 2012 First WG draft on service discovery >>>>>> Feb 2012 First WG draft on perimeter security >>>>>> Feb 2012 Start of routing related work in the relevant routing area >>>>>> working group, if needed >>>>>> Mar 2012 Submission of the prefix configuration draft to the IESG as >>>>>> Standards Track RFC >>>>>> Apr 2012 Submission of the routing draft to the IESG as Informational >>>>>> RFC >>>>>> Sep 2012 Submission of the name resolution draft to the IESG as >>>>>> Standards Track RFC >>>>>> Nov 2012 Submission of the service discovery draft to the IESG as >>>>>> Standards Track RFC >>>>>> Dec 2012 Submission of the perimeter security draft to the IESG as >>>>>> Informational RFC >>>>>> >>>>>> _______________________________________________ >>>>>> fun mailing list >>>>>> fun@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/fun >>>>> >>>>> _______________________________________________ >>>>> fun mailing list >>>>> fun@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/fun >>>> >>>> >>>> This E-mail and any of its attachments may contain Time Warner Cable >>>> proprietary information, which is privileged, confidential, or subject >>>> to copyright belonging to Time Warner Cable. This E-mail is intended >>>> solely for the use of the individual or entity to which it is >>>> addressed. If you are not the intended recipient of this E-mail, you >>>> are hereby notified that any dissemination, distribution, copying, or >>>> action taken in relation to the contents of and attachments to this >>>> E-mail is strictly prohibited and may be unlawful. If you have received >>>> this E-mail in error, please notify the sender immediately and >>>> permanently delete the original and any copy of this E-mail and any >>>> printout. >>> >>> _______________________________________________ >>> fun mailing list >>> fun@ietf.org >>> https://www.ietf.org/mailman/listinfo/fun >> > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > _______________________________________________ > homegate mailing list > homegate@ietf.org > https://www.ietf.org/mailman/listinfo/homegate
- Re: [homegate] [fun] status of the homenet effort Mark Townsley
- Re: [homegate] [fun] status of the homenet effort Weil, Jason
- Re: [homegate] [fun] status of the homenet effort Erik Kline
- Re: [homegate] [fun] status of the homenet effort Mark Townsley
- Re: [homegate] [fun] status of the homenet effort Mark Townsley
- Re: [homegate] [fun] status of the homenet effort JP Vasseur (jvasseur)
- Re: [homegate] [fun] status of the homenet effort Weil, Jason
- Re: [homegate] [fun] status of the homenet effort Ralph Droms
- Re: [homegate] [fun] status of the homenet effort JP Vasseur (jvasseur)
- Re: [homegate] [fun] status of the homenet effort Weil, Jason
- Re: [homegate] [fun] status of the homenet effort Mark Townsley