Subject: [homegate] BoF Logistics & Background

From: Jason Livingood <[email-masked]>
Date: Wed, 21 Oct 2009 16:23:30 -0400

Good news is that we have a BoF in store for IETF 76.  Bad news is we need
your help on tailoring the content appropriately. ;-)

So, here is the logistical info from
https://datatracker.ietf.org/meeting/76/agenda.html
Room Location: Acacia West
Date / Time: Monday, 9 November 2009, from 1520 to 1720 local time
This is just after the afternoon break, so please arrive on time, with your
pockets filled with cookies or soba noodles or whatever snacks they have.
:-)

This is a draft charter that ended up in approval of this BoF:

Proposed Charter:
Access to broadband Internet services use networking technology of one form
or another within the home, small office/home office (SOHO) or small to
medium business (SMB) as the demarcation between the local network and the
Internet. These technologies almost always involve a single entity - which
is not purely a router - called a "home gateway".  This entity connects a
local user or users to various LAN services, providing some basic level of
security.  The majority of Internet users employ home gateways for this
purpose.
 
However, many serious, long-term problems face users of home gateways today.
At the root of many of these problems is the fact that device manufacturers,
and/or the organizations that specify requirements for such devices, are not
certain which IETF standards and best current practices should be supported,
and when/why that support is needed.  As a result of this, millions of
devices are being deployed every year, which do not work with important IETF
protocols, standards, and best practices that are central to the future of
the Internet. 
 
One of the problems in this area appears to be that home gateway vendors are
unclear which RFCs are important, or current, and why they are important and
in what context they matter. Thus, the primary objective of the group is
document a baseline of ³core² RFCs/BCPs which must be supported, followed by
some ³advanced² RFCs/BCPs which are to be considered optional.  The context
and reasoning behind each document which is included should be summarized as
well, in order to improve comprehension of why a given document has been
included.  These things will help improve compatibilities with and
capabilities for use of the Internet of today.  This will include a focus in
areas such as DNS proxy behavior, congestion mechanisms support, and
security. 
 
A secondary problem is compatibility with and capability for the use of the
Internet of tomorrow.  New security needs related to DNS are motivating a
move to DNSSEC.  However, many if not most home gateways cannot handle
DNSSEC, which is expected to be a major problem that could significantly
impede the deployment of DNSSEC globally. Support for IPv6 is also lacking
to a great degree and there is no clear understanding of how such devices
should support IPv6.
 
This working group will not develop new or extend existing Internet
protocols.  Should any such need develop, the chairs will refer the work to
another working group that is chartered to focus on the relevant problem.
 
Proposed Deliverables and Priorities:
The BoF/WG would work to improve the network experience that a SOHO /
residential home user gets when using the Internet.  This includes providing
a tiered specification for what RFCs and BCPs should be supported, in what
order/priority, and in what manner. This will touch on standards such as:
o   IPv6
o   DNSSEC RFCs and BCPs
o   ECN
o   RED (or other queue management)
o   DNS Proxy BCPs
o   Security-Related BCPs
o   Other TBD
 
The group shall prioritize work as follows:
1.    IPv4-related topics
2.    IPv6-related topics
3.    DNS-related topics (DNSSEC, DNS Proxies, etc.)
4.    ECN-related topics (congestion and queue management)
5.    Security-related topics

--> My next message will focus on the agenda for the session <--

//end//

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 25 Oct 2009 08:36:53 -0700

Greetings again. The proposed charter seems good, but it possibly doesn't go far enough.

>Thus, the primary objective of the group is document a baseline of "core" RFCs/BCPs which must be supported, followed by some "advanced" RFCs/BCPs which are to be considered optional.  

Many of the RFCs and BCPs that we will point to have some SHOULD-level and MAY-level requirements in them. A gateway vendor that wants to do the least amount necessary to meet the requirements will tend to not do things at this requirement level.

Further, many RFCs have important security requirements that, in fact, aren't spelled out in the body of the document, but only in the Security Considerations section. (I guess we should all be glad they appear at all, but still...) Some RFCs have MUST-level and SHOULD-level requirements in the Security Considerations, but many just infer the importance of the requirements without explicitly talking about them.

Thus, it is probably not sufficient to simply point to RFCs: we may need to call out specific parts in each RFC as requirements for our target audience. If others agree with me, I would change the above text to read:

Thus, the primary objective of the group is document a baseline of requirements derived from core RFCs which must be supported. A secondary objective is to list desired-but-optional requirements from the same RFCs as well as other, non-core RFCs.

(Editorial note: BCPs are RFCs, so we don't need to list them twice.)

However:

>This working group will not develop new or extend existing Internet protocols.  Should any such need develop, the chairs will refer the work to another working group that is chartered to focus on the relevant problem.

To some extent, we *will* extend the RFCs by changing the requirements levels in a particular context, namely SOHO and SMB gateways. For example, if we say "RFC WXYZ says that the FooBar message SHOULD be supported; for this profile, it MUST be supported", that is an extension. Thus, the sentence above should probably be:

This working group will not develop new Internet protocols, but may create different requirements in the context of home gateways. If the Working Group believe that new protocols are needed, it will refer the problem to the IESG for further work in existing or new Working Groups.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 25 Oct 2009 09:00:49 -0700

>Proposed Charter:
>
>Access to broadband Internet services use networking technology of one form or another within the home, small office/home office (SOHO) or small to medium business (SMB) as the demarcation between the local network and the Internet. These technologies almost always involve a single entity - which is not purely a router - called a "home gateway".  This entity connects a local user or users to various LAN services, providing some basic level of security.  The majority of Internet users employ home gateways for this purpose.

. . .

>The BoF/WG would work to improve the network experience that a SOHO / residential home user gets when using the Internet.  

However, in the first paragraph, we talk about SMB user as well. In Stockholm, there were a bunch of people that agreed that we can't differentiate between SOHO and SMB home gateways that well. If folks here still agree with that, a better wording for the above sentence would be:

The Working Group would work to improve the network experience that a user of a home gateway gets when using the Internet.

(Editorial: the charter is for the WG, not for the BoF.)

>This includes providing a tiered specification for what RFCs and BCPs should be supported, in what order/priority, and in what manner. This will touch on standards such as:
>o   IPv6
>o   DNSSEC RFCs and BCPs
>o   ECN

The idea of "tiered" seems really tortured. In specific, it seems unlikely that we could get broad community agreement on which of security or IPv6 or DNS improvements is the most important, which is the second most important, and so on. There really are only two topics: IPv4 and IPv6. Security, DNS, congestion, and queuing are all inherent in both IPv4 and IPv6 (although they often have slightly different embodiments in each).

A different way to spin this would be:

This means specifying the requirements from different RFCs should be supported in home gateways. This will touch on standards such as:
o   IPv6
o   DNSSEC RFCs and BCPs
o   ECN
o   RED (or other queue management)
o   DNS Proxy BCPs
o   Security-Related BCPs
o   Other TBD
 
The group will create a BCP-level document for home gateways that only support IPv4, and a second BCP-level document for home gateways that only support both IPv4 and IPv6.

Note: during our chartering, we should also consider whether or not we create just one spec that demands inclusion of IPv6 for conformance. That may be too far for some, but it would certainly help lead to better interoperability for users.

--Paul Hoffman, Director
--VPN Consortium

---

From: Jason Livingood <[email-masked]>
Date: Mon, 26 Oct 2009 11:02:43 -0400

Both of those changes seem to make sense to me - thanks for your review and
assistance in tweaking the draft charter.

Jason

On 10/25/09 11:36 AM, "Paul Hoffman" <[email-masked]> wrote:

>> Thus, the primary objective of the group is document a baseline of "core"
>> RFCs/BCPs which must be supported, followed by some "advanced" RFCs/BCPs
>> which are to be considered optional.
> 
> Many of the RFCs and BCPs that we will point to have some SHOULD-level and
> MAY-level requirements in them. A gateway vendor that wants to do the least
> amount necessary to meet the requirements will tend to not do things at this
> requirement level.
> 
> Further, many RFCs have important security requirements that, in fact, aren't
> spelled out in the body of the document, but only in the Security
> Considerations section. (I guess we should all be glad they appear at all, but
> still...) Some RFCs have MUST-level and SHOULD-level requirements in the
> Security Considerations, but many just infer the importance of the
> requirements without explicitly talking about them.
> 
> Thus, it is probably not sufficient to simply point to RFCs: we may need to
> call out specific parts in each RFC as requirements for our target audience.
> If others agree with me, I would change the above text to read:
> 
> Thus, the primary objective of the group is document a baseline of
> requirements derived from core RFCs which must be supported. A secondary
> objective is to list desired-but-optional requirements from the same RFCs as
> well as other, non-core RFCs.
> 
> To some extent, we *will* extend the RFCs by changing the requirements levels
> in a particular context, namely SOHO and SMB gateways. For example, if we say
> "RFC WXYZ says that the FooBar message SHOULD be supported; for this profile,
> it MUST be supported", that is an extension. Thus, the sentence above should
> probably be:
> 
> This working group will not develop new Internet protocols, but may create
> different requirements in the context of home gateways. If the Working Group
> believe that new protocols are needed, it will refer the problem to the IESG
> for further work in existing or new Working Groups.
> 
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Jason Livingood <[email-masked]>
Date: Mon, 26 Oct 2009 11:13:16 -0400

Paul - You made a couple more charter suggestions (which I have cut from
this reply) which were good.  Some feedback below.

> The group will create a BCP-level document for home gateways that only support
> IPv4, and a second BCP-level document for home gateways that only support both
> IPv4 and IPv6.

I think your motivation to narrow scope as much as possible makes sense.
However, I wonder if it would be unduly limiting to constrain the group to
the production of two documents.  I'd love to hear what others think.
 
> Note: during our chartering, we should also consider whether or not we create
> just one spec that demands inclusion of IPv6 for conformance. That may be too
> far for some, but it would certainly help lead to better interoperability for
> users.

I think one spec will prove challenging, but we'll see.

Regards
Jason

---

From: Laurent Toutain <[email-masked]>
Date: Mon, 26 Oct 2009 16:28:17 +0100

Hi,

I'm wondering why the group will not focus on routing protocols (or at least
extensions) for the home environment. On this kind of unmanaged networks,
link capacity is rapidly changing, traffic should be spread over all
available links,... . More ever routers auto-configuration or multi-homing
will be a plus for such architecture.

Laurent

On Mon, Oct 26, 2009 at 16:13, Jason Livingood <
[email-masked]> wrote:

> _______________________________________________
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 26 Oct 2009 10:07:31 -0700

At 4:28 PM +0100 10/26/09, Laurent Toutain wrote:
>I'm wondering why the group will not focus on routing protocols (or at least extensions) for the home environment. On this kind of unmanaged networks, link capacity is rapidly changing, traffic should be spread over all available links,... . More ever routers auto-configuration or multi-homing will be a plus for such architecture.

Few home gateways have more than one WAN link. I say "few" because I am aware that some aimed at the SMB market that have two WAN Ethernet ports. Having said that, it is far from clear that anyone can say what would be a "best current practice" for such home gateways, given the extremely small experience we have.

--Paul Hoffman, Director
--VPN Consortium

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 26 Oct 2009 13:04:49 -0500

At 11:00 AM 10/25/2009, Paul Hoffman wrote:
> >Proposed Charter:
> >
> >Access to broadband Internet services use networking technology of 
> one form or another within the home, small office/home office 
> (SOHO) or small to medium business (SMB) as the demarcation between 
> the local network and the Internet. These technologies almost 
> always involve a single entity - which is not purely a router - 
> called a "home gateway".  This entity connects a local user or 
> users to various LAN services, providing some basic level of 
> security.  The majority of Internet users employ home gateways for 
> this purpose.
>
>. . .
>
> >The BoF/WG would work to improve the network experience that a 
> SOHO / residential home user gets when using the Internet.
>
>However, in the first paragraph, we talk about SMB user as well. In 
>Stockholm, there were a bunch of people that agreed that we can't 
>differentiate between SOHO and SMB home gateways that well. If folks 
>here still agree with that, a better wording for the above sentence would be:
>
>The Working Group would work to improve the network experience that 
>a user of a home gateway gets when using the Internet.

this is a good suggestion - based on the first paragraph

> >This includes providing a tiered specification for what RFCs and 
> BCPs should be supported, in what order/priority, and in what 
> manner. This will touch on standards such as:
> >o   IPv6
> >o   DNSSEC RFCs and BCPs
> >o   ECN
>The idea of "tiered" seems really tortured. In specific, it seems 
>unlikely that we could get broad community agreement on which of 
>security or IPv6 or DNS improvements is the most important, which is 
>the second most important, and so on. There really are only two 
>topics: IPv4 and IPv6. Security, DNS, congestion, and queuing are 
>all inherent in both IPv4 and IPv6 (although they often have 
>slightly different embodiments in each).
>
>This means specifying the requirements from different RFCs should be 
>supported in home gateways. This will touch on standards such as:
>o   IPv6
>o   DNSSEC RFCs and BCPs
>o   ECN
>The group will create a BCP-level document for home gateways that 
>only support IPv4, and a second BCP-level document for home gateways 
>that only support both IPv4 and IPv6.
>
>Note: during our chartering, we should also consider whether or not 
>we create just one spec that demands inclusion of IPv6 for 
>conformance. That may be too far for some, but it would certainly 
>help lead to better interoperability for users.
>
>--Paul Hoffman, Director
>--VPN Consortium

---

From: Lars Eggert <[email-masked]>
Date: Tue, 27 Oct 2009 13:01:22 +0200

Hi,

On 2009-10-26, at 17:28, Laurent Toutain wrote:
> I'm wondering why the group will not focus on routing protocols (or  
> at least extensions) for the home environment. On this kind of  
> unmanaged networks, link capacity is rapidly changing, traffic  
> should be spread over all available links,... . More ever routers  
> auto-configuration or multi-homing will be a plus for such  
> architecture.

the MIF and MPTCP working groups are looking at enabling the use of  
multiple interfaces and paths. Their future results may be something  
that a HOMEGATE recommendation could point to at some point.

(Neither of them deal with routing, however, but I think you didn't  
mean routing in the classical sense of the term anyway.)

Lars

---

From: Laurent Toutain <[email-masked]>
Date: Wed, 28 Oct 2009 14:16:20 +0100

On Mon, Oct 26, 2009 at 18:07, Paul Hoffman <[email-masked]> wrote:

> >I'm wondering why the group will not focus on routing protocols (or at
> least extensions) for the home environment. On this kind of unmanaged
> networks, link capacity is rapidly changing, traffic should be spread over
> all available links,... . More ever routers auto-configuration or
> multi-homing will be a plus for such architecture.
>
> Few home gateways have more than one WAN link. I say "few" because I am
> aware that some aimed at the SMB market that have two WAN Ethernet ports.
> Having said that, it is far from clear that anyone can say what would be a
> "best current practice" for such home gateways, given the extremely small
> experience we have.
>

Yes, but is the working group will cover the case of two or several HOMEGATE
in a home environment. This is not totally science fiction, a user may have
an ADSL and a WiMAX access and a HOMEGATE router for each of them ?

Will HOMEGATE router offer support for routers inside the domestic network
to be auto-configured and routing inside the home network should take into
account some QoS consideration ?

If an answer to one of these questions is yes, I think routing protocols
should be in the scope of the WG.

Laurent

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 28 Oct 2009 08:37:58 -0700

At 2:16 PM +0100 10/28/09, Laurent Toutain wrote:
>Yes, but is the working group will cover the case of two or several HOMEGATE in a home environment. This is not totally science fiction, a user may have an ADSL and a WiMAX access and a HOMEGATE router for each of them ?

That seems like a real scenario, and one that will be more common in the future, but should it be part of this WG? That is, how can we specify best current practices on this type of routing if we don't know what "best" is? It seems like this might be better handled as a few Experimental RFCs now, with a BCP a few years later when we have more experience.

>Will HOMEGATE router offer support for routers inside the domestic network to be auto-configured and routing inside the home network should take into account some QoS consideration ?

They probably will, but we don't know how. We should probably list this in our document as "something homegate vendors should be aware of" without saying what it is best for them to do.

>If an answer to one of these questions is yes, I think routing protocols should be in the scope of the WG.

Again, only if we have something to say about what is "best". Short of that, we can list alternatives that they should consider.

--Paul Hoffman, Director
--VPN Consortium

---

From: Martin Focazio <[email-masked]>
Date: Wed, 28 Oct 2009 12:21:53 -0400

>> "best current practice" for such home gateways, given the extremely small
There are already some gateway devices out there that are using dual WAN
connectivity - wireline + 3G for example. It certainly is an interesting
model, and as LTE wireless comes along, I think that it would not be
unreasonable to think of the wireline WAN connection being "fattened" via a
docked mobile wireless device.

Certainly some support for multiple WAN connection is not an unrealistic
goal at this stage.

---

From: Jason Livingood <[email-masked]>
Date: Wed, 28 Oct 2009 17:01:05 -0400

[JL] It¹s not unreasonable to consider that this may be a focus eventually,
but I believe this is a corner case today (that will grow over time of
course).  As such, it probably makes sense to maintain a focus on
single-homed devices first since we have much to do, affecting a larger
current and potential user base.  We can then get to multi-homed devices
later on, after consulting with the ADs for guidance, so we should keep it
in mind as we proceed.

Jason

---

From: Jason Livingood <[email-masked]>
Date: Wed, 28 Oct 2009 17:25:06 -0400

Based on your feedback, here is an updated charter.  I have one comment
embedded inline in the document for the group here.
--JL

Title: Broadband Home Gateway [HomeGate] BoF
 
Proposed IETF Area: Transport
 
Transport Area Directors:
Lars Eggert ([email-masked])
Magnus Westerlund ([email-masked])
 
BoF Organizers: 
Jason Livingood ([email-masked])
Dave Oran ([email-masked])

Proposed Charter:

One of the problems in this area appears to be that home gateway vendors are
unclear which RFCs are important, or current, and why they are important and
in what context they matter. Thus, the primary objective of the group is
document a baseline of requirements derived from "core" RFCs which must be
supported. A secondary objective is to list desired-but-optional, or
"advanced", requirements from the same RFCs as well as other, non-core RFCs.
The context and reasoning behind each document which is included should be
summarized as well, in order to improve comprehension of why a given
document has been included.  These things will help improve compatibilities
with and capabilities for use of the Internet of today.  This will include a
focus in areas such as DNS proxy behavior, congestion mechanisms support,
and security. 

This working group will not develop new Internet protocols, but may create
different requirements in the context of home gateways. If the Working Group
believes that new protocols are needed, it will refer the problem to the
IESG for further work in existing or new Working Groups.
 
Proposed Deliverables and Priorities:
The Working Group would work to improve the network experience that a user
of a home gateway gets when using the Internet. This means specifying the
requirements from different RFCs should be supported in home gateways. This
will touch on standards such as:
·     IPv6

·     DNSSEC RFCs and BCPs

·     ECN

·     RED (or other queue management)

·     DNS Proxy BCPs

·     Security-Related BCPs

·     Other TBD

The group will create a BCP-level document for home gateways that only
support IPv4, and a second BCP-level document for home gateways that only
support both IPv4 and IPv6.

[JL COMMENT: Is the above sentence overly limiting or constraining?  Thus,
might there be informational documents we may wish to create or have the
option to create?] 

2.    IPv6-related topics

Contributors: ISPs and home gateway developers / vendors
 
Who Uses the Work: Home gateway developers / vendors, ISPs

 [JL1] <#_msoanchor_1> Is this overly limiting?

---

From: Bill Strahm <[email-masked]>
Date: Wed, 28 Oct 2009 08:29:55 -0700

Laurent Toutain wrote:
>
> On Mon, Oct 26, 2009 at 18:07, Paul Hoffman <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     >I'm wondering why the group will not focus on routing protocols
>     (or at least extensions) for the home environment. On this kind of
>     Few home gateways have more than one WAN link. I say "few" because
>     I am aware that some aimed at the SMB market that have two WAN
>     Ethernet ports. Having said that, it is far from clear that anyone
>     can say what would be a "best current practice" for such home
>     gateways, given the extremely small experience we have.
>
>  
> Yes, but is the working group will cover the case of two or several 
> HOMEGATE in a home environment. This is not totally science fiction, a 
> user may have an ADSL and a WiMAX access and a HOMEGATE router for 
> each of them ?
>
> Will HOMEGATE router offer support for routers inside the domestic 
> network to be auto-configured and routing inside the home network 
> should take into account some QoS consideration ?
>
> If an answer to one of these questions is yes, I think routing 
> protocols should be in the scope of the WG.
>
> Laurent
Please just say no to this extra complexity.  Seriously, what percentage 
of the market do you expect to have multiple WAN connections to the 
internet, when people switch to WiMAX - they will stop paying their 
34.99 to their ADSL provider and start paying it to their WiMAX 
provider.  If we are to start taking on what would normally be 
considered Enterprise level protocols (do we expect these things to 
start supporting BGP next?) the specifications will be so complicated 
that no company will bother to implement them.

Step 1: Find a nice 80% of your user base use cases
Step 2: Hyper optimize for the majority of the users
Step 3: Simplify Simplify Simplify - only do as much as needed for the 
simple cases - and no more
Step 4: Think about advanced features.

Bill

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 29 Oct 2009 10:09:44 +0100

[cc to shim6 list, prune as required]

Shim6ers: there is currently a discussion on the (fairly) new homegate  
list about whether multiple home gateways would have to run a routing  
protocol between them.

On 28 okt 2009, at 16:29, Bill Strahm wrote:

> Please just say no to this extra complexity.  Seriously, what  
> percentage of the market do you expect to have multiple WAN  
> connections to the internet

Well, this is exactly the deployment scenario for Shim6.

For Shim6 to work, the hosts must be able to use different addresses  
from different ISPs. If you have two IPv6 routers that both announce a  
different prefix, that can work well.

There is no need for the two routers to coordinate. There is the issue  
of what happens when a packet with a source address from ISP A ends up  
on the router connected to ISP B, but this issue can be solved by the  
host paying attention to which router it sends which packets to.  
Having the routers sort this out would be more complex, I don't think  
simply running a routing protocol solves this. The only way this  
becomes a show stopper is if there are the two routers connected to  
ISPs A and B, and then there is a third router connected to the first  
two, and hosts sit behind the third one. In this case the hosts can't  
direct packets to the right router, so the routers would have to sort  
things out.

Bottom line: as long as multiple routers can live on a subnet without  
getting in each other's way, we have 90% of what we need, so let's go  
for that now and see what more we can do at some later time.

> Step 3: Simplify Simplify Simplify - only do as much as needed for  
> the simple cases - and no more

It's good to optimize for the most common use cases, but it's also  
important to not break the remaining 20% for fear of pushing towards a  
monoculture. See what happened in the web browser space.

---

From: [email-masked]
Date: Thu, 29 Oct 2009 09:17:03 +0000

> [JL] It’s not unreasonable to consider that this may be a focus 
> eventually, but I believe this is a corner case today (that will 
> grow over time of course).  As such, it probably makes sense to 
> maintain a focus on single-homed devices first since we have much to
> do, affecting a larger current and potential user base.  We can then
> get to multi-homed devices later on, after consulting with the ADs 
> for guidance, so we should keep it in mind as we proceed.

+1 to that.

Let's get the basics done right, first!

Ray