Hi, Sabine: 发件人: Randriamasy, Sabine (Nokia - FR) [mailto:[email protected]] 发送时间: 2016年4月9日 0:19 收件人: Qin Wu; Gao Kai; Gurbani, Vijay (Nokia - US); IETF ALTO 抄送: Y. Richard Yang 主题: RE: [alto] Rebooting ALTO (or how to avoid the "low energy" label)
Hi Vijay, Qin, Kai and all, Thanks a lot for these discussions and apologies for my late reaction. I also took a deeper look at the IETF91 meeting material and the ALTO-YANG work as a non expert in YANG. My take and suggestions are the following: ALTO has strong high-level abstractions (PID, EP Cost Service, Network Maps) that aid in reasoning at higher levels and are useful regardless of fixed, wireless or cellular networks (quoting Vijay). [Qin]: Good point, Network MAP and Cost MAP for wireless /cellular network is no different from Network MAP and Cost MAP for fixed network. ALTO hides complexity and sensitive information, so it can assist North Bound Interfaces (NBIFs) of SDN Controllers as a query service for network topologies. For NBIFs on top of the routing layer, TE metrics abstracted from the routing layer are needed. Higher layer NBIF features such as Intent models are being designed to express policy requirements in a simple way or for applications to place network service requests in a way that is agnostic to the technology of the involved network infrastructure. One input needed to express an Intent is a high level topology spanning different layers, access technologies and devices. ALTO/JSON conveys topology information with readable and light-weight messages while YANG/NETCONF/RESTCONF allows an in-depth "access" to its composing devices and is widely used for fixed networks. If ALTO information can be modeled with YANG and easily transcoded in JSON it will be an advantage for YANG based network management systems. This would also allow to easily stitch ALTO information based on YANG and JSON. There is no standard to represent cellular networks for which JSON based models seem pretty popular and topologies for future applications span multiple access technologies. The ALTO WG has some footprint in SDOs that can be leveraged. To start with: - a SDNRG presentation at IETF95 on Intent-based Policy management cites ALTO and I2RS as possible input data to policy intent, see slide 26 of https://www.ietf.org/proceedings/95/slides/slides-95-sdnrg-1.pdf. [Qin]: Good observation, I think the accurate interpretation to your first observation is SUPA will used ALTO data as input to define SUPA model. - Qin mentioned references to ALTO in IDR and I2RS. - ETSI has reported the ODL ALTO implementation work in its Dec. 2015 report on SDN usage in NFV framework, The ALTO WG past work went largely in that direction, with "composite" topologies and its generic encoding, ALTO for high bandwidth, mobile and cellular networks, cost metric and properties extensions etc... So how about list discussions related to requirements for ALTO to support modern use cases? For example and to be updated: - topology extensions to span cellular, any-access point, end-user devices, data center, switches etc... involved in an application? [Qin]: I am not sure I understand your first proposal, what topology extension is required to support cellular, I thought network topology for fixed has no difference with topology for cellular. Please Correct me if I am wrong, also I am aware in the wirelss/celluar world, TOSCA instead of YANG is used to model topology. But TOSCA is complementary to YANG since TOSCA is mostly used to instantiate NFV instance rather than provide run-time congfiuration. - accessing particular versions of a Network or Cost Map when an application runs on several ISP topology configurations, - gap analysis on the YANG 2 JSON interpreters, [Qin]: This concurs with my proposal, I am happy to contribute if such work is needed. - ... Any thoughts? Great thanks for reading, Sabine De : alto [mailto:[email protected]] De la part de EXT Qin Wu Envoyé : samedi 26 mars 2016 03:31 À : Gao Kai; Gurbani, Vijay (Nokia - US); IETF ALTO Cc : Y. Richard Yang Objet : Re: [alto] Rebooting ALTO (or how to avoid the "low energy" label) 发件人: Gao Kai [mailto:[email protected]] 发送时间: 2016年3月22日 9:50 收件人: Vijay K. Gurbani; Qin Wu; IETF ALTO 抄送: Y. Richard Yang 主题: Re: [alto] Rebooting ALTO (or how to avoid the "low energy" label) Hi Vijay, Qin and all, Please see below for details. On 22/03/16 01:52, Vijay K. Gurbani wrote: Qin Wu writes: Hi, Vijay: Thank for raising discussion on this. Qin: Thanks for starting a discussion on this. I was wondering why no one had picked up on the mail to start a thread. 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. Great. I would think that you'd want to be in a position by the Berlin IETF to make a short presentation to RTG area to intimate the WGs there on the draft. We authors plan to revive alto te metric draft and keep on proceeding it in the upcoming IETF meeting. Good. 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? Is ALTO a modeling language? I don't think so. But I will be the first to admit that my YANG knowledge is not up to par with that of others in the working group, who I hope will hold a more insightful discussion on this topic, and in the process educate me. I think ALTO is not a modelling language. However, we do use some kind of modelling in the ALTO RFCs/drafts. For example, the models related to IRD are provided in RFC 7285, section 9.2.2. Theoretically we should be able to use YANG to model the ALTO protocol. Unfortunately, YANG (or more precisely the current YANG-to-JSON & JSON-to-YANG interpreters) doesn't support the key-value syntax which is widely used in ALTO. [Qin]: Good observation, I am wondering why not extend JSON encoding for data modeled with YANG to support additional feature provided by YANG. One approach is that we use YANG to model the protocol but provide a customized interpreter. [Qin]: If we want to use NETCONF/RESTCONF to configure the ALTO protocol, sure we can use YANG to model ALTO protocol, If we think of ALTO as Query protocol or ALTO is just used to query data from ALTO server, I think we should more care about JSON encoding for ALTO data modeled with YANG. Clearly, the emergence of YANG has stymied the efforts of certain work items in ALTO. It will be an excellent start for someone (Richard Y?) to provide a summary on the relevant issues we need to discuss here to move some of the work forward and indeed, to formulate a response --- if one is needed --- on the use of YANG in ALTO. Cheers, - vijay Regards, Kai
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
