Hi Richard, I am aware of the scenarios where the ISP effectively owns and manages the residential gateway. These are the cases where this problem is easily solved. However, in my (admittedly limited) experience in this matter, these cases are
I’ll concede that the draft doesn’t duly acknowledge this reality, and it should. But that issue was not the primary concern in the draft. There are two cases that remain interesting: - I live in a country (Australia) where it is rare for an ISP to own and operate CPE. - Even as newer Broadband Forum specifications are implemented and deployed, there are a large number of areas operating on old specifications. I know of many people who are still getting 256k/512k/1.5mbps on old equipment. In many cases, this equipment is adequate for their needs even though it is long beyond the end of its support period. This statement is entirely incorrect: > Unlike location services, ALTO is a service that's seen as tightly-coupled > with an ISP's infrastructure. Location *services* might not have any binding to access network infrastructure, if you are thinking of navigation or where is the nearest X type of service. That's not what GEOPRIV is developing. GEOPRIV protocols are about talking to a server that has an understanding of network topology as well as it's relationship to the physical world so that it can provide the device with location information. By that token, the discovery problem in GEOPRIV the same as ALTO. I hope that clears up any misunderstanding, --Martin --- From: Richard Bennett [mailto:[email protected]] Sent: Friday, 27 March 2009 11:16 AM To: Thomson, Martin Cc: Matt Lepinski; [email protected]; Winterbottom, James Subject: Re: [alto] ALTO Discovery and draft-ietf-geopriv-lis-discovery My primary employer is a provider of residential gateways to major ISPs, and I find that this document doesn't reflect my experience. Let me explain. North American telco ISPs supply a residential gateway to their customers as part of their Internet access (or triple-play) service. This goes for AT&T, Verizon, and Qwest. Some cable MSOs do as well, but the larger cable MSOs (Comcast and Time-Warner.) The telco RGs support the DSL Forum's TR069 protocol, which permits the operator to push firmware updates into these devices, change configurations, and and run diagnostics. These ISPs see the RG as a part of their network infrastructure. It's perfectly practical for the telco ISPs to update the firmware in their TR069-controlled RG's to support a new feature in the ISP's network such as the ALTO route selector. And in fact, the specific mechanisms that rely on vendor-defined options in the DHCP payload are similar to features in use today to support some IPTV functions. TR069-controlled RGs probably make up something like 30-40% of the market in the US today; I can't comment on the situation in other countries. To the extent that RGs should be seen as intractable obstacles to new protocols and services, the culprits are the devices sold through the retail channel that aren't ISP-controllable. These devices raise a number of interesting problems for the deployment of services that enhance and extend such things as DSCP markings, DNS, and DHCP payloads, and in fact simply for faster Internet connections. Upgrade your Comcast connection to the new DOCSIS 3.0 service and you may find your old RG can't keep up. Hence, the cable MSO user community is already in a position where some features are not available to them if their RG is below par. Unlike location services, ALTO is a service that's seen as tightly-coupled with an ISP's infrastructure. Hence, it's reasonable to assume that ISPs who wish to offer this service will be in a position to either: A) upgrade the relevant RGs to support it; or B) Tell the customer how to upgrade his RG to support it. The software for the retail RGs tends to come from a limited number of sources, so adding a new feature isn't as hard as it may appear. Ultimately, almost all of this stuff is based on Busybox Linux. I hope this helps. RB Thomson, Martin wrote: I also wanted to point out that there is what I believe to be a reasonably good problem statement regarding the problem as it relates to residential gateways in the document: http://tools.ietf.org/html/draft-thomson-geopriv-res-gw-lis-discovery There is also some discussion in the document on solutions, but I wouldn't dwell on those overmuch. --Martin -----Original Message----- From: Matt Lepinski [mailto:[email protected]] Sent: Thursday, 26 March 2009 3:03 PM To: [email protected] Cc: Thomson, Martin; Winterbottom, James Subject: ALTO Discovery and draft-ietf-geopriv-lis-discovery Just wanted to quickly re-iterate a point that Martin Thomson had made during today's ALTO meeting. GEOPRIV has been working (for well over a year) on the following problem: "How does a device locate a server providing a given service that is topologically close (in a network topology sense) to the device" In the case of GEOPRIV, the service in question is a 'Location Information Server (LIS)', but a believe that the problem of discovering a "local" (in a network topology sense) alto server has many similar challenges as the GEOPRIV discovery problem. Based on my experience in GEOPRIV, I believe that getting this type of discovery to work well in all cases is quite hard (especially if one has security concerns regarding an attacker who may try to impersonate a legitimate provider of the service [be it ALTO or LIS]). Currently, the work in GEOPRIV is still incomplete, but I would encourage anyone whose been thinking about ALTO discovery to read draft-ietf-geopriv-lis-discovery-08, and if you have any insights on how to improve the GEOPRIV document based on your experience with ALTO, please send comments to the GEOPRIV list (and the authors). Also, perhaps we can get several people who have been thinking about GEOPRIV discovery to review the ALTO discovery documents. (I'm happy to volunteer, though I'm definitely not as much of an expert on this topic as Martin and James, who I have been kind enough to CC <grin>). - Matt Lepinski ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
