Re: [fun] status of the homenet effort
"Weil, Jason" <jason.weil@twcable.com> Fri, 01 July 2011 13:33 UTC
Return-Path: <jason.weil@twcable.com>
X-Original-To: fun@ietfa.amsl.com
Delivered-To: fun@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03AF811E80FD; Fri, 1 Jul 2011 06:33:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.864
X-Spam-Level:
X-Spam-Status: No, score=0.864 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753]
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 iggWFojARrgh; Fri, 1 Jul 2011 06:33:40 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id F3EB911E8127; Fri, 1 Jul 2011 06:32:27 -0700 (PDT)
X-SENDER-IP: 10.136.163.10
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.65,458,1304308800"; d="scan'208";a="244804822"
Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 01 Jul 2011 09:31:04 -0400
Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Fri, 1 Jul 2011 09:32:12 -0400
From: "Weil, Jason" <jason.weil@twcable.com>
To: Mark Townsley <mark@townsley.net>, "JP Vasseur (jvasseur)" <jvasseur@cisco.com>
Date: Fri, 01 Jul 2011 09:32:11 -0400
Thread-Topic: [fun] status of the homenet effort
Thread-Index: Acw380h/wVPhDWgST5W2OIltGtCygA==
Message-ID: <CA3341C2.4C55%jason.weil@twcable.com>
In-Reply-To: <C6B9766C-6759-4E6D-8FF7-C8F6C1DFC016@townsley.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.0.0.100825
acceptlanguage: en-US
Content-Type: text/plain; charset="euc-kr"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "fun@ietf.org" <fun@ietf.org>, "homegate@ietf.org" <homegate@ietf.org>
Subject: Re: [fun] status of the homenet effort
X-BeenThere: fun@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "FUture home Networking \(FUN\)" <fun.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fun>, <mailto:fun-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fun>
List-Post: <mailto:fun@ietf.org>
List-Help: <mailto:fun-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fun>, <mailto:fun-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jul 2011 13:33:42 -0000
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. > >> * 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.
- [fun] status of the homenet effort Jari Arkko
- Re: [fun] status of the homenet effort Mark Townsley
- Re: [fun] status of the homenet effort Weil, Jason
- Re: [fun] status of the homenet effort Erik Kline
- Re: [fun] status of the homenet effort Mark Townsley
- Re: [fun] status of the homenet effort Jari Arkko
- Re: [fun] status of the homenet effort Mark Townsley
- Re: [fun] status of the homenet effort Soohong Daniel Park
- Re: [fun] status of the homenet effort JP Vasseur (jvasseur)
- Re: [fun] status of the homenet effort Jari Arkko
- Re: [fun] status of the homenet effort Daniel Park
- Re: [fun] status of the homenet effort Mikael Abrahamsson
- Re: [fun] status of the homenet effort Mark Townsley
- Re: [fun] status of the homenet effort Robert Raszuk
- Re: [fun] status of the homenet effort Mark Townsley
- Re: [fun] status of the homenet effort Weil, Jason
- Re: [fun] [homegate] status of the homenet effort Ralph Droms
- Re: [fun] [homegate] status of the homenet effort JP Vasseur (jvasseur)
- Re: [fun] [homegate] status of the homenet effort Weil, Jason
- Re: [fun] [homegate] status of the homenet effort Mark Townsley
- Re: [fun] status of the homenet effort Jari Arkko
- Re: [fun] status of the homenet effort Robert Raszuk
- [fun] Routing ? Cullen Jennings
- Re: [fun] Routing ? Jari Arkko
- Re: [fun] Routing ? Mikael Abrahamsson
- Re: [fun] Routing ? JP Vasseur (jvasseur)
- Re: [fun] Routing ? Ralph Droms (rdroms)
- Re: [fun] Routing ? Cullen Jennings
- Re: [fun] Routing ? Joel Jaeggli
- Re: [fun] Routing ? Fred Baker
- Re: [fun] Routing ? Cullen Jennings
- Re: [fun] status of the homenet effort Joel Jaeggli