Hi all, interesting discussion.
I hope there is "silent" ongoing work using ALTO that may bring higher energy labels (maybe following the controversy Gartner cycles Trough of Disillusionment?) In our case (academic work with industry ties) we are doing some work on delivering ALTO services using BGP data at public IXPs: Danny Alex Lachos Perez, Samuel Henrique Bucke Brito, Ramon dos Reis Fontes, Christian Esteve Rothenberg. "Delivering Application-Layer Traffic Optimization Services based on Public Routing Data at Internet eXchange Points". In the 34rd Brazilian Symposium on Computer Networks and Distributed Systems (SBRC 2016), Jun 2016. https://dl.dropboxusercontent.com/u/15183439/pubs/2016-SBRC16-ALTO-IXP-152187.pdf Comments welcome and looking forward to contribute to the ALTO developments Cheers, Christian On Fri, Apr 15, 2016 at 2:18 PM, Randriamasy, Sabine (Nokia - FR) <[email protected]> wrote: > Hi Qin, > > > > please see inline, > > Sabine > > > > > > De : EXT Qin Wu [mailto:[email protected]] > Envoyé : lundi 11 avril 2016 14:15 > À : Randriamasy, Sabine (Nokia - FR); 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) > > > > 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. > > [SR ] agree, we currently have most ingredients to represent them all. > > > > 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. > > [SR ] and ALTO may be useful in other frameworks to assist Network > Service Intent . > > > > - 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. > > [SR ] I mean we should continue the work already started in ALTO on > extensions for topology, path vectors, property names to offer a common > framework to represent such topologies. > > 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. > > [SR ] indeed, but ALTO is for another usage: ALTO is a higher level > representation that may abstract a patchwork based on multiple networks and > their respective representations. > > > > - 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. > > [SR ] great > > - ... > > > > 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 > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
