Re: [fun] [homegate] status of the homenet effort

On Jul 1, 2011, at 5:06 PM, Weil, Jason wrote:

> Agreed. My thought was Homenet builds consensus on what work is needed and possibly sets the requirements. The development work should occur in whatever group is responsible for that technology.

I think homenet could set defaults (not far removed from requirements, and something that is imperative in a home network and less so in others). Also, depending on the protocol involved, there may or may not be a WG setup to do the work - for example, DHCP's modus operandi is that simple DHCP options are defined not in the DHC WG itself, but in the "parent technology" WG with review from DHC. 

In any case, I think this is why Jari included a  review stage of the work to be done after we get through the architecture/framework... We'll know better then what work can be knocked out under a homenet banner, and what needs to be forked elsewhere. 

- Mark

> 
> Jason
> 
> -----Original Message-----
> From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]
> Sent: Friday, July 01, 2011 11:02 AM
> To: Ralph Droms (rdroms); Weil, Jason
> Cc: mark@townsley.net; fun@ietf.org; homegate@ietf.org
> Subject: Re: [homegate] [fun] status of the homenet effort
> 
> Agreeing with Ralph.
> 
> JP Vasseur
> Cisco Fellow
> 
> Sent from Blackberry
> 
> ----- Original Message -----
> From: Ralph Droms (rdroms)
> Sent: Friday, July 01, 2011 09:37 AM
> To: Weil, Jason <jason.weil@twcable.com>
> Cc: Mark Townsley <mark@townsley.net>; JP Vasseur (jvasseur); fun@ietf.org <fun@ietf.org>; homegate@ietf.org <homegate@ietf.org>
> Subject: Re: [homegate] [fun] status of the homenet effort
> 
> 
> 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.
> 
>>>> * 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."
> 
> Source/dest aware protocol sounds more like a research project.  Developing requirements might be in scope for homenet.
> 
> - Ralph
> 
>>> 
>>> - 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
> 