Hi, Vijay: Thank for raising discussion on this. Socializing multi-cost and alto-calendar is a good idea, I also think we should socialize ALTO cost metric draft since this draft is a companion document of alto-calendar draft and it interacts with many routing area WGs on how to use measurement data provided by routing system data source and RFC7471 and RFC7752 even provide a clear ALTO use case. We authors plan to revive alto te metric draft and keep on proceeding it in the upcoming IETF meeting.
Regarding developing policy using ALTO or JSON, I am afraid this has potential overlapping with SUPA since YANG defined policy can be translated into either XML format or JSON format and YANG is used to generate API, it could be RESTful API or PlugRestful API. Do we think ALTO is another modeling language besides YANG? -Qin -----邮件原件----- 发件人: alto [mailto:[email protected]] 代表 Vijay K. Gurbani 发送时间: 2016年3月10日 7:22 收件人: IETF ALTO 主题: [alto] Rebooting ALTO (or how to avoid the "low energy" label) Folks: Pursuant to the "State of the WG" thread [1], a number of WG participants (Richard Y., Sabine R., Wendy R., Jensen Z., Gao, K) exchanged some thoughts as a prelude to a larger WG discussion. This email serves as a summary of the the ideas exchanged by them and the start of a larger WG discussion. Clearly there is a need to reboot ALTO. The protocol is stable, the abstractions in the protocol (PID, endpoint cost service, network maps) are sound and very useful, but perhaps what is lacking is a proselytizing push of the protocol to other WGs who may have an interest in the capabilities offered by ALTO but may not be aware of it. Richard Yang noted that there is a large body of interest in ALTO outside of the IETF: - The ALTO project in OpenDaylight [2] - Use of ALTO at Yale, Caltech, and other institutions (Richard, please fill in with more communities of interest ...) - Early use of ALTO in service provider networks This is a good sign in the generality of the protocol and the acceptance of it. Beyond this, there are other avenues that hold promise to raise the profile of ALTO: 1) At the risk of wading into politics, the WG has to avoid the "low- energy" label, which has known to be detrimental in other non-technical spheres. To this extent, the larger working group has to be more engaged in list discussions, reviewing documents, and evangelizing the protocol within IETF. The WG has seen strong contributions from Lyle Bertz, Haibin Song, Lingli Deng, among others, and these contributions are very much appreciated and encouraged. A number of WG participants have been reviewing documents over the last few weeks. A note of appreciation to Gao Kai, Jensen Zheng, and Qiao Xiang is in order ... thanks to all. 2) Take a look at other WGs to see how ALTO may help. Sdnrg, i2rs and supa come to mind, although this is by no means an exhaustive list. The work in ALTO on multi-cost and alto-calendar may could be of interest to sdnrg and should be shared with them more formally. Regarding i2rs, while ALTO will not --- and should not --- serve as a southbound interface, it has the capacity and capability to serve as one of the northbound interfaces [3]. Supa develops models to express policies using YANG, could it also develop policies using ALTO? Clearly, YANG and ALTO are oriented towards two different layers, the former is designed for controlling and querying network devices while the latter has strong high-level abstractions (PID, endpoint cost service, network maps) that aid in reasoning at higher levels. While YANG is predominantly focused on fixed networks, ALTO abstractions are useful regardless of fixed, wireless, or cellular networks. Can supa use these abstractions to develop policies for applications? 3) Evangelize/proselytize/market ALTO in area-wide meetings, such as tsvarea or opsarea. The plan is to prepare an overview of the ALTO protocol and its advantages in time for a slot at the Berlin IETF tsvarea meeting. So ... what to you folks think? How do we reboot ALTO and maintain its relevance? Any further thoughts and ideas expressing them would be great. Thanks for reading so far! [1] https://www.ietf.org/mail-archive/web/alto/current/msg02996.html [2] https://wiki.opendaylight.org/view/ALTO:Main [3] Gurbani, V.K., Scharf, M., Lakshman, T.V. and Hilt, V., "Abstracting network state in Software Defined Networks (SDN) for rendezvous services," In Workshop on Software Defined Networks (SDN), held in conjunction with IEEE International Conference on Communications (ICC), June 2012. - vijay -- Vijay K. Gurbani, Bell Laboratories, Nokia Networks 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / [email protected] Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
