Subject: Re: [alto] Rebooting ALTO (or how to avoid the "low energy" label)

From: "Randriamasy, Sabine (Nokia - FR)" <[email-masked]>
Date: Fri, 8 Apr 2016 16:19:29 +0000

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). 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 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?
- 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,
- ...

Any thoughts?

Great thanks for reading,
Sabine

De : alto [mailto:[email-masked]] 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-masked]]
发送时间: 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

---

From: Qin Wu <[email-masked]>
Date: Mon, 11 Apr 2016 12:15:15 +0000

Hi, Sabine:

发件人: Randriamasy, Sabine (Nokia - FR) [mailto:[email-masked]]
发送时间: 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)

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.

[Qin]: Good observation, I think the accurate interpretation to your first observation is SUPA will used ALTO data as input to define SUPA model.

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.

[Qin]: This concurs with my proposal, I am happy to contribute if such work is needed.
- ...

Any thoughts?

Hi Vijay, Qin and all,

Good.

Cheers,

- vijay

Regards,
Kai

---

From: "Randriamasy, Sabine (Nokia - FR)" <[email-masked]>
Date: Fri, 15 Apr 2016 17:18:26 +0000

Hi Qin,

please see inline,
Sabine

De : EXT Qin Wu [mailto:[email-masked]]
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:

[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.

[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 .

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.

[SR     ] great
- ...

Any thoughts?

Hi Vijay, Qin and all,

Good.

Cheers,

- vijay

Regards,
Kai

---

From: Christian Esteve Rothenberg <[email-masked]>
Date: Wed, 20 Apr 2016 18:29:27 -0300

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-masked]> wrote:
> 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.
>
>
>
> - 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.
>
> 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,
>
> 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.
>
>
>
> [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.
>
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>