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

["JP Vasseur (jvasseur)" <[e-mail]>]

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 <[e-mail]>
Cc: Mark Townsley <[e-mail]>; JP Vasseur (jvasseur); [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
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" <[e-mail]> 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:[e-mail]]
>>> Sent: Thursday, June 30, 2011 11:36 AM
>>> To: Weil, Jason <[e-mail]>
>>> Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
>>> 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" <[e-mail]> wrote:
>>>> 
>>>>> 
>>>>> All,
>>>>> 
>>>>> Apologies for double-posting if there are folks that are subscribed to
>>>>> [e-mail] and [e-mail]. I'm hoping soon that someone will
>>>>> finally create [e-mail] 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 <[e-mail]>
>>>>>> Jari Arkko <[e-mail]>
>>>>>> 
>>>>>> Internet Area Advisor:
>>>>>> Jari Arkko <[e-mail]>
>>>>>> 
>>>>>> Routing Area Technical Advisor:
>>>>>> TBD
>>>>>> 
>>>>>> Security Area Technical Advisor:
>>>>>> TBD
>>>>>> 
>>>>>> Mailing Lists:
>>>>>> General Discussion: [e-mail]
>>>>>> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/fun
>>>>> 
>>>>> _______________________________________________
>>>>> fun mailing list
>>>>> [e-mail]
>>>>> 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
>>> [e-mail]
>>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homegate