Hi Enrico, all, I fully agree that the relationship between I2RS and ALTO requires careful thinking, because possibly guidance to the I2RS WG is needed. This is a timely topic, and I thank the authors of draft-song-alto-i2rs to bring this to the attention of the working group.
However, I wonder whether draft-song-alto-i2rs is a useful starting point for this discussion. Please find my concerns on the technical content below. I understand that this document is at an early stage, but in my opinion it is still not heading in the right direction. Title, Abstract, Introduction, and Terminology ---------------------------------------------- The title, abstract, and the introduction are fairly generic. While the acronym I2RS is never expanded in the text, and any reference is missing, I assume here that the new I2RS working group is implied implicitly. As far as I understand the planned work in I2RS, this new IETF working group discusses specific interactions with the Internet routing system. Apart from a short text in Section 4, draft-song-alto-i2rs-01 does not discuss I2RS specifically. Section 3.1 ----------- The following section seems interesting, but I fail to see an actual contribution: An ALTO server needs the following information as input: o The network segments information. Every access router manages one or more IP address pools, to be assigned to the users through DHCP or other ways." What is the difference between "network segment information" and entries in "routing tables" (next bullet)? The IP address pools will have to used in routing as well. Does the document suggest an interface between I2RS and a RADIUS server? That would probably have to be discussed in the I2RS WG, I don't know if this is foreseen there. o The IP addresses of the interfaces of routers, and the routing table information(IGP or BGP). This o information can help to construct the whole network topology. Yes, but I2RS is not needed for that. See for instance draft-ietf-idr-ls-distribution. Also, note that an ALTO server almost certainly does not want to expose IP addresses of routers or router interfaces, as explained e. g. in draft-scharf-alto-vpn-service-00. o The congestion status of the router interfaces, but this information could be reflected in the routing table change I think it has always been consensus that ALTO will not expose short-term "congestion" status. From draft-ietf-alto-protocol-14: "Recall that while ALTO may convey dynamic network information, it is not intended to replace near-real-time congestion control protocols." Under the assumption that congestion here implies "long-term" interface utilization, this text would have to distinguish whether it refers to the load on the interfaces to each individual residential user, on the Internet-facing interfaces, etc. The latter seems to be closer related to draft-amante-i2rs-topology-use-cases-00 than the former, but I might be wrong. Note that congestion status towards a residential user could depend on the traffic class (e. g., different congestion status for Internet access vs. IPTV) and many other parameters. o Policy information, for example, one multi-homing AS prefers to use which AS to transit its traffic, including the pricing information. Agreed on the first points, this is what I2RS seems to be all about. I am curious how to retrieve pricing information from the routing system. Section 3.2 ----------- This section is closely related to draft-lee-alto-ext-dc-resource. I don't see how that whole section matters to I2RS or ALTO. More specifically: The ALTO server needs to collect the following information so as to provide this kind of service. o All switches' network capacity information Unless I miss something, I2RS addresses routers, not switches. o All physical servers' information(CPU, memory) in the data center And this will be retrieved from the Internet routing system? How? o The storage space information in the data center Same here? o The physical links information Inside the data center one often has L2/Ethernet connectivity, i.e., no routing system. Apart from that detail, what link information specifically? o The virtual machines' information(CPU, memory) and its affinity Same as above. o Pricing models Again, I don't see the relation to I2RS for that. Based on the previous informaiton, ALTO server can provide the load balancing/traffic optimization informaiton to ALTO client for data centers, through map or ranking. In summary, this list is to a large extend not about networking, and unrelated to I2RS, as far as I understand it. What do I miss? Section 4 --------- So there could be two ways to go forward. (1) Defining a new protocol for all the functions(configuration and disclosure) required by I2RS. This protocol covers ALTO's south bound information requirements on network topology, with its one component. But this protocol will be tremendously complicated. It will be related and overlapped with many existing protocols, such like NetConf and YANG. This seems to discuss protocols that I2RS may develop at some point in time. And the authors seem to believe that a future I2RS solution will be sufficient for ALTO. This is hypothetical, and it will depend on the ALTO use case. But if the assumption is right, it will not require any short-term action of ALTO. Not doing anything is certainly a realistic option for ALTO. But this also implies that this document is not required. (2) Defining the south bound interface for ALTO, to collect the infrastructure information, and bring the requirements discussion in I2RS, and identify the final scope, to avoid the overlap between different WGs(ALTO, NetConf, NetMod). The protocol development will go to ALTO. I strongly disagree that ALTO should develop a protocol to "collect the infrastructure information". This would fully overlap with other IETF work like draft-ietf-idr-ls-distribution and other solutions, and with a high probability also with whatever I2RS may work on. Therefore, this is no solution. I think that it could be worthwile to discuss in ALTO a third way: (3) Document the specific ALTO requirements for narrow-focused, well-known ALTO use-cases, e. g., in an information model, and provide those requirements to the I2RS WG. No protocol development will be needed in ALTO. This would have to be a very detailed requirement analysis of what information is needed by ALTO, where the corresponding data is typically present in the Internet routing system, how it can be retrieved in a given ALTO use case, and what gaps may exist in current technologies. This may require substantial amount of work in the ALTO WG beyond generic hand-waving. For instance, it would require agreement on use cases, deployment scenarios of ALTO, how network and cost maps are compiled, etc. I have doubts whether there is enough energy on that. In summary, this is a relevant topic, but I believe that there are other, lower-hanging fruits for new work items in ALTO. Thanks Michael > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Enrico Marocco > Sent: Wednesday, February 20, 2013 10:03 AM > To: [email protected] > Subject: Re: [alto] new individual document notification > > I believe this effort is very useful. The i2rs WG is in fact > considering the ALTO protocol as a candidate for some of the > use cases they are focusing on (see e.g. > http://tools.ietf.org/html/draft-amante-i2rs-topology-use-case > s-00#section-4.3). > The more information ALTO experts can provide to help them > make an informed decision, the better. I would encourage > anyone who have been involved in the development of the ALTO > protocol to coordinate with Haibin and Young, and help people > outside the WG understand whether the work done here could be > a good match for their needs. > > Enrico > > On 2/19/13 4:17 AM, Songhaibin (A) wrote: > > Hi all, > > > > > > > > We have submitted a new individual document. > > > > http://tools.ietf.org/html/draft-song-alto-i2rs-00 > > > > > > > > Which is aimed to focus on gathering infrastructure information for > > ALTO service. I think it could be called the south bound > interface for ALTO. > > This document is also related to i2rs wg. Anybody who has the same > > interest to contribute is welcome to join us, we plan to give an > > update by next Monday. > > > > > > > > Regards! > > > > -Haibin > > > > > > > > > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
