Hi all, Sorry to spam the list with one more work-in-progress update email. But since it is an important, chartered task of the WG, we would like to hear your feedback and invite more to be involved to work together.
The openalto.org team has two main objectives: (1) design and implement a high-quality, open-source implementation of ALTO server; and (2) integrate openalto.org with real application use cases. We plan to provide detailed updates during the coming IETF'115 ALTO meeting in 3 weeks on Nov. 11 and this email is to provide a quick overview of progress and thinking. The openalto implementation and use cases are complementary to the implementation and use cases by others such as the wonderful project at Telefonica by Luis. First, on (1), at the surface, ALTO only defines an interface, and the true complexity and value of an ALTO server implementation is the process of obtaining the information resources for an ALTO server to expose. The current openalto implementation focuses on providing 3 types of implementations: (A1) from configuration, adjacency, and other input such as BGP inputs, (A2) from reading FIB directly, and (A3) from available sampling FIB (e.g., s-flow/netflow report, traceroute essentially sampling by ttl and ICMP report). So far good process has been made for A2 (for looking glass for CERN and others) and A3 (based on s-flow, and others, on top of G2 led by Jordi and Sruthi). There are also efforts to make progress on A1, using batfish and there is ongoing work to apply the approach to ESnet. Building on the progress of having many ALTO servers running, the openalto team includes a new effort to organize the existing ALTO servers. Although there are existing ALTO server discovery mechanisms, openalto.org will now serve as a frontend to many servers which will become available soon. One major departure of this approach from the original ALTO thinking is that openalto allows multiple ALTO servers to serve a single network. Hence, openalto.org is organized as a structure motivated by the DNS structure, as <entity>.<domain>.openalto.org. For example, as513.lg.openalto.org is the ALTO server for entity AS513 (CERN) implemented by A3 (Looking Glass server) domain. Hence, the deployment structure is an overlay structure, with base servers that can be overridden by authoritative servers. We feel that this is a great way to go. In addition to serving as a hub of network composition, the current openalto.org will also serve as a frontend to provide a unified query interface to existing networking information. An example that will be deployed is to make ALTO a frontend to geoip data, in the domain of geoip.openalto.org. For (2), the current focus of openalto is for two applications: the application-layer scheduling integration into FTS, which is the main scheduling system at LHC and many others; and Rucio, which is the transfer selection/data orchestration framework. For FTS, openalto provides the important assets that a transfer utilizes and then the scheduler, which knows the app and the amount of data transferred, can conduct application-level resource partition among multiple application-level entities (experiments/projects/activities). For Rucio, openalto provides distance (cost map) as a unifying abstraction, including FTS distance, to guide the transfer selection. These use cases are different from other use cases such as those described by Luis. We welcome feedback and broad participation. Please let us know if you can help. Thanks, The openalto team
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
