Subject: [homegate] April Workshop: Agenda Bashing

From: Jason Livingood <[email-masked]>
Date: Tue, 06 Apr 2010 12:42:45 -0400

Our most recent agenda is at
http://trac.tools.ietf.org/area/tsv/trac/wiki/HOMEGATE

Our main objective in the next several days is to finalize the agenda for
the workshop.  I am working with all of the people on the cc list, so if you
have any suggested changes please be sure they and the list are copied on
replies.

Thanks
Jason

---

From: Jason Livingood <[email-masked]>
Date: Tue, 06 Apr 2010 13:04:33 -0400

In my haste, I¹ve left off the correct folks on the cc list for agenda
feedback (duh).  

The workshop organizers above are: Lars Eggest, Jari Arkko, Dave Oran, Mark
Townsley, Ray Bellis, and Jason Livingood

J

On 4/6/10 12:42 PM, "Jason Livingood" <[email-masked]>
wrote:

> Our main objective in the next several days is to finalize the agenda for the
> workshop.  I am working with all of the people on the cc list, so if you have
> any suggested changes please be sure they and the list are copied on replies.
> 
> Thanks
> Jason

---

From: Jason Livingood <[email-masked]>
Date: Tue, 06 Apr 2010 13:09:01 -0400

On our agenda we have several slots for vendors to present.  When we drafted
the agenda, we envisioned vendors possibly discussing the state of their
deployed gear (with respect to DNSSEC, IPv6, security threats, etc.), how/if
units are field-upgradable, the status of support in current/future gear,
any confusion over specs that homegate could help with, and other thoughts
about either potential value add for homegate or conflicts/problems with
homegate.

We are happy to adjust timeslots to provide more or less time for device
companies to present, and even to add more slots.

If you work at such a company, we¹d like you to consider presenting.  Please
email the organizers on the cc list to advise of your interest.

We have a tentative list of companies that may fit in this role:
1  Cisco/Linksys 
2  2wire
3  Thompson
4  Apple
5  NetGear
6  D-Link
7  SMC
8 - Belkin
9 - AVM
10 - TI
11 - Broadcom
12 - Wind River
13 - Gatespace
14 - Certicom
15 - Freescale
16 - Mocana
17 - TeamF1
> Thanks!!
                        Jason

---

From: Mark Townsley <[email-masked]>
Date: Wed, 7 Apr 2010 14:46:45 +0200

Getting a readout on the state of CPE deployment is a good thing to have. We
do need to know where we are in order to know where we want to go. But, I
think we would be far better served with a short survey from vendor
participants that are attending as well as those that are not, and someone
to present and summarize the results.

Then I'd rather see a call for problem areas to discuss, preferably with an
internet draft or other document to review in advance from the folks
advocating for time. If we have problems that people are working on that
match with our CPE data, great. If not, perhaps we need to try and drum up
support in a specific area.

I'd also like to know what other SDOs/Forums are working on, and what they
would like to see from the IETF here. In this case, I'd hope to see someone
present that can speak in a reasonably authoritative manner on what that SDO
is doing, so we know where and where not to step.

Finally, I'd like to understand better architecturally why a homegate is or
is not a classic host or a router, and whether we (the IETF) need to
consider it as a different device altogether or not.

This is the kind of information, I think, that will help us formulate what
the IETF should or should not do in this space. Frankly, I don't want to see
a list of vendor or SP presentations, I don't think we have time for that,
and it would likely give us a very sparse view of the problem space as well.

- Mark

Also - I know this isn't fully an IETF meeting, but in the spirit of an IETF
meeting let's focus on the problems we are trying to solve, not our company
affiliations. We're predominantly individuals here, and while we may be
biased by our paychecks and our expertise is certainly shaped by the work
that we do, we are certainly not able to speak in a binding manner on behalf
of our companies here unless one of us happens to be the CEO or majority
shareholder.

On Tue, Apr 6, 2010 at 7:09 PM, Jason Livingood <
[email-masked]> wrote:

>  On our agenda we have several slots for vendors to present.  When we
> drafted the agenda, we envisioned vendors possibly discussing the state of
> their deployed gear (with respect to DNSSEC, IPv6, security threats, etc.),
> how/if units are field-upgradable, the status of support in current/future
> gear, any confusion over specs that homegate could help with, and other
> thoughts about either potential value add for homegate or conflicts/problems
> with homegate.
>
> If you work at such a company, we’d like you to consider presenting.
>  Please email the organizers on the cc list to advise of your interest.
>
> 1 – Cisco/Linksys
> 2 – 2wire
> 3 – Thompson
> 4 – Apple
> 5 – NetGear
> 6 – D-Link
> 7 – SMC
> _______________________________________________
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate
>
>

---

From: "Heather Kirksey" <[email-masked]>
Date: Wed, 7 Apr 2010 10:20:22 -0500

Mark,

I take your point about not wanting to hear a stream of vendor presentations at the meeting.  On the other hand, in list discussion and at the BoF, I've definitely heard all sorts of statement or anecdotes presented as facts about what this market is, what the CPE vendors care about, and how they design their products, but I feel as though we've heard little from the vendors themselves.  To be blunt, I feel that most of the support for Homegate is not coming from the CPE vendors themselves but rather other constituencies.  To me that says something (whether good or bad I don't know), and I'd really like to hear some vendor voices.

I also think it's very important to realize that there are very distinct subsets of this industry as well:  vendors that sell mainly to/through service provider channels (whether cable or telco) and vendors that sell mainly through retail.  Within the telco channel at least (which is my area of expertise compared to retail or cable), there is a pretty big difference in the drivers for a company that's doing "higher end" products with more cutting edge features in close collaboration with their customers and those for a company that's providing a more cost conscious "standard" product.  I think would be somewhat naïve on our part to treat the Homegate vendors as an undifferentiated mass, and understanding the perspectives of different subsets of it could be enlightening. 

That being said, obviously a bunch of company pitches would hardly be a good use of our time.  Too much presentation, not enough discussion would also probably not be a good use of our time.  There's a balance to be struck here, but I really do believe that we need to hear a great deal more from the folks who would theoretically be the target audience of the work coming out of this group.  

Just my $.02.  I think the architectural question you raise is quite interesting, by the way.

Thanks,

Heather 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Townsley
Sent: Wednesday, April 07, 2010 7:47 AM
To: Jason Livingood
Cc: Ray Bellis; [email-masked]
Subject: Re: [homegate] April Workshop: Agenda - CALL FOR VENDORPRESENTATIONS

Getting a readout on the state of CPE deployment is a good thing to have. We do need to know where we are in order to know where we want to go. But, I think we would be far better served with a short survey from vendor participants that are attending as well as those that are not, and someone to present and summarize the results. 

Then I'd rather see a call for problem areas to discuss, preferably with an internet draft or other document to review in advance from the folks advocating for time. If we have problems that people are working on that match with our CPE data, great. If not, perhaps we need to try and drum up support in a specific area.

I'd also like to know what other SDOs/Forums are working on, and what they would like to see from the IETF here. In this case, I'd hope to see someone present that can speak in a reasonably authoritative manner on what that SDO is doing, so we know where and where not to step.

Finally, I'd like to understand better architecturally why a homegate is or is not a classic host or a router, and whether we (the IETF) need to consider it as a different device altogether or not.

This is the kind of information, I think, that will help us formulate what the IETF should or should not do in this space. Frankly, I don't want to see a list of vendor or SP presentations, I don't think we have time for that, and it would likely give us a very sparse view of the problem space as well.

- Mark

Also - I know this isn't fully an IETF meeting, but in the spirit of an IETF meeting let's focus on the problems we are trying to solve, not our company affiliations. We're predominantly individuals here, and while we may be biased by our paychecks and our expertise is certainly shaped by the work that we do, we are certainly not able to speak in a binding manner on behalf of our companies here unless one of us happens to be the CEO or majority shareholder.

On Tue, Apr 6, 2010 at 7:09 PM, Jason Livingood <[email-masked]> wrote:

On our agenda we have several slots for vendors to present.  When we drafted the agenda, we envisioned vendors possibly discussing the state of their deployed gear (with respect to DNSSEC, IPv6, security threats, etc.), how/if units are field-upgradable, the status of support in current/future gear, any confusion over specs that homegate could help with, and other thoughts about either potential value add for homegate or conflicts/problems with homegate.

We are happy to adjust timeslots to provide more or less time for device companies to present, and even to add more slots.

If you work at such a company, we'd like you to consider presenting.  Please email the organizers on the cc list to advise of your interest.

1 - Cisco/Linksys 
2 - 2wire
3 - Thompson
4 - Apple
5 - NetGear
6 - D-Link
7 - SMC
8 - Belkin
9 - AVM
10 - TI
11 - Broadcom
12 - Wind River
13 - Gatespace
14 - Certicom
15 - Freescale
16 - Mocana
17 - TeamF1

Thanks!!
Jason

On 4/6/10 12:42 PM, "Jason Livingood" <[email-masked]> wrote:

Our most recent agenda is at http://trac.tools.ietf.org/area/tsv/trac/wiki/HOMEGATE

Our main objective in the next several days is to finalize the agenda for the workshop.  I am working with all of the people on the cc list, so if you have any suggested changes please be sure they and the list are copied on replies.

Thanks

                       Jason

---

From: "Duncan Bees" <[email-masked]>
Date: Wed, 7 Apr 2010 08:34:17 -0700

All,

Vendor perspective is great, but one suggestion is to allocate enough time
for each SDO to fully explain their work and approach regarding Home
Gateways; I think we have 30 minutes at present which seems a little thin
(presumably that also includes discussion and/or questions). 

I guess we need an understanding of what each group is already doing, and
what/why/how Homegate plans to do the complement that work. 

Duncan

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Heather Kirksey
Sent: April-07-10 8:20 AM
To: Mark Townsley; Jason Livingood
Cc: Ray Bellis; [email-masked]
Subject: Re: [homegate] April Workshop: Agenda - CALL FOR
VENDORPRESENTATIONS

Mark,

I take your point about not wanting to hear a stream of vendor presentations
at the meeting.  On the other hand, in list discussion and at the BoF, I’ve
definitely heard all sorts of statement or anecdotes presented as facts
about what this market is, what the CPE vendors care about, and how they
design their products, but I feel as though we’ve heard little from the
vendors themselves.  To be blunt, I feel that most of the support for
Homegate is not coming from the CPE vendors themselves but rather other
constituencies.  To me that says something (whether good or bad I don’t
know), and I’d really like to hear some vendor voices.

I also think it’s very important to realize that there are very distinct
subsets of this industry as well:  vendors that sell mainly to/through
service provider channels (whether cable or telco) and vendors that sell
mainly through retail.  Within the telco channel at least (which is my area
of expertise compared to retail or cable), there is a pretty big difference
in the drivers for a company that’s doing “higher end” products with more
cutting edge features in close collaboration with their customers and those
for a company that’s providing a more cost conscious “standard” product.  I
think would be somewhat naïve on our part to treat the Homegate vendors as
an undifferentiated mass, and understanding the perspectives of different
subsets of it could be enlightening. 

That being said, obviously a bunch of company pitches would hardly be a good
use of our time.  Too much presentation, not enough discussion would also
probably not be a good use of our time.  There’s a balance to be struck
here, but I really do believe that we need to hear a great deal more from
the folks who would theoretically be the target audience of the work coming
out of this group.  

Just my $.02.  I think the architectural question you raise is quite
interesting, by the way.

Thanks,

Heather 

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mark Townsley
Sent: Wednesday, April 07, 2010 7:47 AM
To: Jason Livingood
Cc: Ray Bellis; [email-masked]
Subject: Re: [homegate] April Workshop: Agenda - CALL FOR
VENDORPRESENTATIONS

- Mark

On Tue, Apr 6, 2010 at 7:09 PM, Jason Livingood
<[email-masked]> wrote:

If you work at such a company, we’d like you to consider presenting.  Please
email the organizers on the cc list to advise of your interest.

Thanks!!
Jason

Thanks

                       Jason

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 7 Apr 2010 09:25:31 -0700

I can't tell what all might be discussed in the presentations, but I am hoping
there will be discussion that many home gateways will soon be in "new"
environments including:

  * being behind a carrier's NAT44, resulting in a system (of the 
    home's NAT44 and the carrier's NAT44) that is commonly called
    "NAT444".

    Would be interesting/useful to know if/how the home gateways
    will deal with that.  draft-wing-softwire-port-control-protocol 
    is one way to deal with one aspect of a NAT444 system.  There
    are other aspects of a NAT444 system, including overlapped
    IP address space, optimized routing of traffic behind the
    carrier's NAT, and more.

  * IPv6, via dual-stack or 6rd.

  * IPv4 multicast for IPTV.

separately, will anything be said about NAT44 ALGs during the two days?  SIP
ALG, RTSP ALG, H.323 ALG, PPTP "ALG", IPsec/IKE "ALG", etc.  IETF has
historically ignored NATs (and firewalls) and effectively ignored ALGs in
those same devices.  In our experience with home gateways, ALGs are a panacea
which have interfered with application evolution.

-d

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jason Livingood
> Sent: Tuesday, April 06, 2010 10:05 AM
> To: [email-masked]
> Cc: Ray Bellis
> Subject: Re: [homegate] April Workshop: Agenda Bashing
> 
> In my haste, I've left off the correct folks on the cc list 
> for agenda feedback (duh).  
> 
> The workshop organizers above are: Lars Eggest, Jari Arkko, 
> Dave Oran, Mark Townsley, Ray Bellis, and Jason Livingood
> 
> 
> J
> 
> On 4/6/10 12:42 PM, "Jason Livingood" 
> 	Our main objective in the next several days is to 
> finalize the agenda for the workshop.  I am working with all 
> of the people on the cc list, so if you have any suggested 
> changes please be sure they and the list are copied on replies.
> 	
> 	Thanks
> 	Jason
> 	
> 
>

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Wed, 7 Apr 2010 17:53:31 +0100

Please forgive me if this goes to somebody who doesn't want it, i.e., because it is interfering with your meeting arrangements.

On 7 Apr 2010, at 13:46, Mark Townsley wrote:
Finally, I'd like to understand better architecturally why a homegate is or is not a classic host or a router, and whether we (the IETF) need to consider it as a different device altogether or not.

This caught my attention, so I felt I'd take a stab at it.  In reality you've puzzled me as much.  I have twice considered just throwing money away and buying a Cisco service router to do my home networking, or else getting a Soekris box and building my own.  But I ended up just sticking with one of Apple's base stations, in no small part because it also did backups.  So I think I'm qualified to at least vent my frustration. :-)

Here is why a home gateway is a home gateway, now and in the future:
* Integrated connectivity technology (DSL, cable, home power)
* Integrated home automation or discovery for service provision (voice lines, cameras, printers, grid control, speakers, hard drives)
* Reduced security and configuration policy (home users don't need BGP, and the defaults should work for them, while configuration should be possible for "Advanced" users, including allowing potentially abused services)
* Out of the box for common home scenarios (NAT44/64/Softwire, dynamic DNS update, IPv6 native/transitional, NTP)
* Common apps, gateways and configuration (NAT-PMP, UPnP, ALGs, working DNSProxy, tunnels and tunnels, voice, DHCP passthrough, et. al)
* As far as possible, future-proof: firmware upgradable, maybe provider management.
* Personal: no provider/vendor lock-in on any of the above, thanks so much.  Interoperate!

Now, you can make the convincing argument that all that is just a simple router with some host functionality slapped in the same box, and you'd be right.  Well, in Linux you change a single sysctl and you've got the same.  The point is that whatever it is comes straight from the provider, more often than not, and that it frequently isn't even running the latest firmware, so whatever it is has to be pretty much switch-on-and-forget.

Cheers,
Sabahattin

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Apr 2010 10:04:52 -0700

>    IP address space, optimized routing of traffic behind the

This is critical. In a few tests I have done, home gateways that get their WAN address by DHCP and then get a private-address-space address do wildly different things:
- Work
- Lock up silently
- Repeatedly request a different DHCP address

--Paul Hoffman, Director
--VPN Consortium

---

From: Mark Townsley <[email-masked]>
Date: Fri, 9 Apr 2010 20:10:38 -0700

Fully agree that getting a clear read on the running code is a good thing to
have - I was calling for a survey in advance rather than a series of vendor
presentations. This takes time and effort though. If someone wants to
volunteer to do this, I would be very grateful. It might just be simply too
late for this... So, instead, we have to develop the consolidate picture on
the fly at the meeting, which just seems a bit less efficient than it could
be. C'est la vie.

- Mark

On Wed, Apr 7, 2010 at 8:20 AM, Heather Kirksey <[email-masked]> wrote:

>  Mark,
>
>
>
> I take your point about not wanting to hear a stream of vendor
> presentations at the meeting.  On the other hand, in list discussion and at
> the BoF, I’ve definitely heard all sorts of statement or anecdotes presented
> as facts about what this market is, what the CPE vendors care about, and how
> they design their products, but I feel as though we’ve heard little from the
> That being said, obviously a bunch of company pitches would hardly be a
> good use of our time.  Too much presentation, not enough discussion would
> also probably not be a good use of our time.  There’s a balance to be struck
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Mark Townsley
> *Sent:* Wednesday, April 07, 2010 7:47 AM
> *To:* Jason Livingood
> *Cc:* Ray Bellis; [email-masked]
> *Subject:* Re: [homegate] April Workshop: Agenda - CALL FOR
> VENDORPRESENTATIONS
>
>
>
>
> Getting a readout on the state of CPE deployment is a good thing to have.
> We do need to know where we are in order to know where we want to go. But, I
> Also - I know this isn't fully an IETF meeting, but in the spirit of an
> IETF meeting let's focus on the problems we are trying to solve, not our
> company affiliations. We're predominantly individuals here, and while we may
> be biased by our paychecks and our expertise is certainly shaped by the work

---

From: Ole Troan <[email-masked]>
Date: Sat, 10 Apr 2010 10:44:54 +0200

The "Basic IPv6 CE router requirements" are standardised in v6ops.
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-04

during this effort we punted all the hard issues to a phase 2 document "The Advanced IPv6 CE router requirements" document.

during the v6ops meeting in Anaheim, there was a brief discussion on where to home this work. I believe v6ops is happy to continue this work, but with the charter of homegate and the fact that a number of the punted issues are "IP agnostic" I would like to request an agenda slot for this work.
(http://www.ietf.org/proceedings/10mar/slides/v6ops-2.pdf)

I expect we'll also discuss scope/charter of homegate separately, but consider my view that this should be within.

punt list (draft):
============
1.QoS
2.Service Discovery
3.DNS
4.Multicast
5.Arbitrary complex topologies
    1.Prefix sub-delegation
    2.Routing in the LAN
    3.…
6.IPv6 transition mechanisms
7.(IPv6 only (NAT64))
8.Firewall pinholing / PCP
9.Multi-homing (also to non-congruent topologies)
   1.NAT66
   2.SAS/DAS policy
10.Advanced security
11.Zeroconf

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Sat, 10 Apr 2010 11:15:41 +0200

> Fully agree that getting a clear read on the running code is a good thing to have - I was calling for a survey in advance rather than a series of vendor presentations. This takes time and effort though. If someone wants to volunteer to do this, I would be very grateful. It might just be simply too late for this... So, instead, we have to develop the consolidate picture on the fly at the meeting, which just seems a bit less efficient than it could be. C'est la vie.

I would be happy to do the work and summarize, but as far as I've seen on the list. has a single vendor yet put their hands up to speak at the workshop yet?

cheers,
Ole

---

From: Mark Baugher <[email-masked]>
Date: Sat, 10 Apr 2010 10:45:19 -0700

> I would be happy to do the work and summarize, but as far as I've seen on the list. has a single vendor yet put their hands up to speak at the workshop yet?

Some of the speakers are from companies that build and/or market home networking gear.  Is that what you're asking Ole?  

Mark

---

From: Ole Troan <[email-masked]>
Date: Sat, 10 Apr 2010 19:52:09 +0200

Mark,

> Some of the speakers are from companies that build and/or market home networking gear.  Is that what you're asking Ole?  

sort of. I see that the agenda is still referencing "device vendor <1..4>". are those slots filled?
have we heard from any of the 17+ CPE vendors listed on the wiki page?

cheers,
Ole

---

From: Jason Livingood <[email-masked]>
Date: Sun, 11 Apr 2010 09:00:17 -0400

> have we heard from any of the 17+ CPE vendors listed on the wiki page?

Not yet, I don't think.  We have lots of messages out to vendors on that
page, some appear to have registered but not sure we have firm commitments
for those slots as of yet.  That said, I've been on vacation so I may have
missed an email.

Jason

---

From: Ole Troan <[email-masked]>
Date: Wed, 14 Apr 2010 11:55:46 +0200

Jason et al,

I haven't seen a reply to this or any changes in the agenda.

even though the interim meeting is a workshop with other SDOs. I'd like us to spend at least a half day or so on technical issues. I think the punt list from the IPv6 CE router requirements effort is as good a starting point as any.

I'd like us to spend some time understanding the problems. do an initial stab at where the problem should be solved and who does it.

could we do this e.g first half of day 2?

cheers,
Ole

---

From: Jari Arkko <[email-masked]>
Date: Wed, 14 Apr 2010 13:30:00 +0300

This is a great list, thanks. We need more lists like this. Some
comments inline below.

I like to think about the homegate discussions in terms of
understanding what specifications we already have in the different
standards bodies (IPv6 node requirements and the like), identifying
potential gaps, and figuring out where should the work take place to
fill out the gaps. Note that gaps may include both actual lack of
specification for some piece of functionality or lack of a top-level
document that would point to all the small pieces of specification that
already exist.

punt list (draft):
============
1.QoS

Perhaps, but it is also critical that we decide what issues really need
to be specified. In particular, we do not need to burden simple
gateways with mandatory functionality that is not needed in vast
majority of cases.

2.Service Discovery
3.DNS

We already have http://tools.ietf.org/html/rfc5625 but more maybe
needed. What?

4.Multicast

.... and arbitrarily complicated specification.  I'm not sure we should
address this except for few well known cases. Such as PD.

http://tools.ietf.org/html/draft-arkko-ipv6-deployment-guidelines is
one intended answer for the global recommendations. I have not thought
about what that means for home gateways, but that's certainly an
interesting topic. What should a homegateway support? Surely dual
stack, but is that it?

7.(IPv6 only (NAT64))

See above.

This has been the topic of multi-year research projects and multiple
competing working group designs.

1.NAT66

I hope we don't go here.

2.SAS/DAS policy

Indeed. But the specifications from 6MAN to provide policy distribution
are not ready yet.

10.Advanced security

What's this?

11.Zeroconf

What were you thinking of saying here?

Jari

cheers,
Ole

---

From: Jari Arkko <[email-masked]>
Date: Wed, 14 Apr 2010 14:23:20 +0300

Dan,

Yes, this is an interesting topic.

Yes. I would argue dual stack is something that we should recommend.
There are plenty of optional mechanisms that some gateways may choose
to implement on top of that, though.

Hmm. How widely is multicast used for IPTV, and are these deployments
similar or do they use widely different ways of delivery over IP (such
as multicast vs. unicast)?

Also, I understand that a gateway box is often also an IPTV stream
termination point (convert IP to HDMI, for instance). However, isn't it
then working in a role of a host? Is there something generic that we
can say about *gateways* and multicast IPTV?

separately, will anything be said about NAT44 ALGs during the two days? SIP
ALG, RTSP ALG, H.323 ALG, PPTP "ALG", IPsec/IKE "ALG", etc.

Maybe you should tell us whether that's something that should be
discussed, and whether standardization in that space is helpful or
harmful. What was the outcome of the ALG Bar BoF in IETF-77?

Jari

IETF has

-d

-----Original Message-----

J

Thanks
Jason

---

From: David R Oran <[email-masked]>
Date: Wed, 14 Apr 2010 09:08:57 -0400

> Dan,
[snip]
> Hmm. How widely is multicast used for IPTV,
very. Tons of SSM. Millions of users in multiple countries.

> and are these deployments similar
The ones that use Microsoft Mediaroom tend to be pretty similar :-)
So are the ones that use Cisco ISDP. There are a bunch of home-grown systems (Free in France, FastWeb in Italy) as well. In terms of their use of multicast and L3 in general they are essentially identical; the differences tend to be in QoS provisioning and higher layer stuff (e.g. mediaroom uses some proprietary microsoft RTP extensions).

> or do they use widely different ways of delivery over IP (such as multicast vs. unicast)?
Over-the-top systems (e.g. ESPN360) use HTTP/TCP delivery and hence look much like a web application for the point of view of IP, NAT, etc. In fact one big reason they are done this way is the port 80 spanning layer they have to use to reach through the wide variety of user connections.
> 
> Also, I understand that a gateway box is often also an IPTV stream termination point (convert IP to HDMI, for instance).
I've seen these beasts, but they are uncommon, and tend to be things like Pace media server boxes or DOCSIS STBs that work as whole-home DVRs.
In other words there are some all-in-one boxes out there but they are less common and often are specifically made to look like hosts straight on the SP's access network as opposed to a host+gateway crammed in a single box.

> However, isn't it then working in a role of a host? Is there something generic that we can say about *gateways* and multicast IPTV?
Yes. Things like IGMP proxies, support of IGMPv3, plus a bunch of other stuff I can't recall at the moment.

DaveO.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 14 Apr 2010 16:27:37 +0300

David,

Ok. Thanks for the explanation. I am convinced.

Jari

DaveO.

---

From: Ole Troan <[email-masked]>
Date: Wed, 14 Apr 2010 15:32:41 +0200

Jari,

> This is a great list, thanks. We need more lists like this. Some comments inline below.
> 
> I like to think about the homegate discussions in terms of understanding what specifications we already have in the different standards bodies (IPv6 node requirements and the like), identifying potential gaps, and figuring out where should the work take place to fill out the gaps. Note that gaps may include both actual lack of specification for some piece of functionality or lack of a top-level document that would point to all the small pieces of specification that already exist.  

agree.

[...]

>> punt list (draft):
>> ============
>> 1.QoS
>>   
>> 
> 
> Perhaps, but it is also critical that we decide what issues really need to be specified. In particular, we do not need to burden simple gateways with mandatory functionality that is not needed in vast majority of cases.

BBF has a fairly extensive definition of how an RG should do classification, shaping etc. available in WT-124. probably motivated by applications like VOIP.

I wouldn't expect/hope that any new protocols would have to be specified for QoS. so if homegate would do anything on this bullet, it would be more along the lines of specifying that an RG must be able to do Diffserv marking etc.

btw: this list is not prioritized.

the WT-124 as well as this list comes from the viewpoint of the RG/CPE/home-gateway. should this group also consider issues of networking within the home? 

>> 2.Service Discovery
>> 3.DNS
>>   
>> 
> 
> We already have http://tools.ietf.org/html/rfc5625 but more maybe needed. What?

should we even recommend that the RG acts as a DNS proxy?
what about being an authoritative name-server for the reverse zone for the delegated prefix for example?

this is a prime example of an issue which should be discussed next week. is it a problem? do we need to specify how DNS in the home should work without management? unlikely to be new protocol work required here too.

> .... and arbitrarily complicated specification.  I'm not sure we should address this except for few well known cases. Such as PD.

so we already have the issue of multi-level NAT today. where customers have chained two NATs. typically one from the SP and one from retail. today there is no way to make this work with IPv6 without manual configuration. with IPv4 it just works (for some definition of works).

from there you can move on to slightly more complex topologies. we're back to the set of problems with drove the work on multi-link subnets and zero configuration routers a few years back.

> http://tools.ietf.org/html/draft-arkko-ipv6-deployment-guidelines is one intended answer for the global recommendations. I have not thought about what that means for home gateways, but that's certainly an interesting topic. What should a homegateway support? Surely dual stack, but is that it?

right, so this is more in the land of product profiles. the BBF has already specified quite a bit here.

> This has been the topic of multi-year research projects and multiple competing working group designs.

yep, there are a few deployed networks with these problems today. I certainly also have it at home, with the use of my companies VPN connection.

> I hope we don't go here.

hard to see that we don't have to unless the below gets more traction...

> 
>>    2.SAS/DAS policy
>>   
>> 
> 
> Indeed. But the specifications from 6MAN to provide policy distribution are not ready yet.

right, and is that the correct solution?
as this has consequences for the nodes inside the home. and more wide-arching consequences if we want to solve this for a home network with multiple levels (multiple routers), is this something we should take on in homegate?

> What's this?

http://tools.ietf.org/html/draft-vyncke-advanced-ipv6-security-01

> What were you thinking of saying here?

I think it was covered by the plug and play routing part / service discovery.

I should perhaps another point to the list.

12. Renumbering

in some cases home networks may go through 'flash renumbering'. i.e no overlapping between old and new prefix.

cheers,
Ole

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 14 Apr 2010 10:35:21 -0700

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Wednesday, April 14, 2010 4:23 AM
> To: Dan Wing
> Cc: [email-masked]
> 	    will deal with that.  
> draft-wing-softwire-port-control-protocol 
> Yes. I would argue dual stack is something that we should 
> recommend. There are plenty of optional mechanisms that some 
> gateways may choose to implement on top of that, though.
> 
> 
> 

More and more every day.  Microsoft and other vendors have 
live deployments.

> and are these 
> deployments similar or do they use widely different ways of 
> delivery over IP (such as multicast vs. unicast)?
> 
> Also, I understand that a gateway box is often also an IPTV 
> stream termination point (convert IP to HDMI, for instance). 

Sometimes, yes -- with that model, there might just be unicast
inside the home network to other televisions, using a 'master'
multicast IPTV receiver which integrates the cablemodem or FTTH
connection so it is also the home gateway and thus does everything
correctly.

Another model is that each IPTV receiver is fully capable of 
receiving multicast and there is multicast in the home network. 
In that model, the home gateway might be clueless about IPTV
but needs to pass IGMP and multicast traffic from/to the IPTV 
receivers inside the home network.

> However, isn't it then working in a role of a host? Is there 
> something generic that we can say about *gateways* and multicast IPTV?

They need to proxy IGMP and handle multicast, per RFC5135.

> Maybe you should tell us whether that's something that should 
> be discussed, and whether standardization in that space is 
> helpful or harmful. What was the outcome of the ALG Bar BoF 
> in IETF-77?

>From my perspective, the ALG Bar BoF outcome was that the
proponents still believe IETF could be successful standardizing
ALGs, and dissenters still believe IETF would not have success
in standardizing ALGs.  I am in the latter camp.

-d

> 		<[email-masked]> 
> <mailto:[email-masked]>  wrote:
> 		
> 		
>

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 16 Apr 2010 10:31:55 -0400

On Apr 14, 2010, at 9:27 AM, Jari Arkko wrote:

>> Yes. Things like IGMP proxies, support of IGMPv3, plus a bunch of  
>> other stuff I can't recall at the moment.
>>
>

Possible topics

IGMPv3 support (needed)

MLDv2 support (needed)

IGMP / MLD snooping (unclear to me if this will ever be wanted /  
needed, but if the
gateway is linking, say, a wired and wireless home LAN it probably  
will be.)

IGMP / MLD proxies (needed for lots of real-world links)

ATM support (http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast-10 
  - having a gateway with a built in AMT gateway would be an excellent  
idea IMO).

If I missed anything, please feel free to chime in.

Regards
Marshall

---

From: "David Harrington" <[email-masked]>
Date: Sun, 18 Apr 2010 01:56:13 -0400

Hi,
 
We may need to develop best current practices, and
"expected-to-be-best future practices"
 
dbh

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jari Arkko
Sent: Wednesday, April 14, 2010 7:23 AM
To: Dan Wing
Cc: [email-masked]
Subject: Re: [homegate] April Workshop: Agenda Bashing

Dan,

I can't tell what all might be discussed in the presentations, but I
am hoping

environments including: 

    "NAT444".

    carrier's NAT, and more.

Also, I understand that a gateway box is often also an IPTV stream
termination point (convert IP to HDMI, for instance). However, isn't
it then working in a role of a host? Is there something generic that
we can say about *gateways* and multicast IPTV?

separately, will anything be said about NAT44 ALGs during the two
days?  SIP

Jari

  IETF has

historically ignored NATs (and firewalls) and effectively ignored ALGs
in

those same devices.  In our experience with home gateways, ALGs are a
panacea

-d

-----Original Message-----

To: [email-masked]

Cc: Ray Bellis

J

 <mailto:[email-masked]>
<[email-masked]> wrote:

	Thanks

	Jason

homegate mailing list

[email-masked]