Re: [homegate] [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: 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 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
X-Mailman-Approved-At: Fri, 01 Jul 2011 07:02:54 -0700
Cc: "fun@ietf.org" <fun@ietf.org>, "homegate@ietf.org" <homegate@ietf.org>
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 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.