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

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 9 Mar 2016 17:22:19 -0600

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-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: Qin Wu <[email-masked]>
Date: Mon, 21 Mar 2016 07:30:22 +0000

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-masked]] 代表 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.

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:

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.

- vijay

_______________________________________________
alto mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/alto

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 21 Mar 2016 12:52:18 -0500

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

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

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

---

From: Gao Kai <[email-masked]>
Date: Tue, 22 Mar 2016 09:50:20 +0800

Hi Vijay, Qin and all,

Please see below for details.

> 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.  One approach is that we use YANG to model the
protocol but provide a customized interpreter.
> --- if one is needed --- on the use of YANG in ALTO.

Regards,
Kai

---

From: Qin Wu <[email-masked]>
Date: Sat, 26 Mar 2016 02:23:58 +0000

Sorry for late reply, please see my reply inline below.
-----邮件原件-----
发件人: Vijay K. Gurbani [mailto:[email-masked]] 
发送时间: 2016年3月22日 1:52
收件人: Qin Wu; IETF ALTO
抄送: Y. Richard Yang; RANDRIAMASY, SABINE (SABINE)
主题: Re: [alto] Rebooting ALTO (or how to avoid the "low energy" label)

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

> system data source and RFC7471 and RFC7752 even provide a clear ALTO 

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.

[Qin]: Sure, if we can proceed alto-calendar and alto te metrics more quickly, I can give a presentation to RTG area.

Good.

[Qin]: It looks there is no F2F meeting for ALTO in BA. However we authors believe this draft is ready for WG adoption together with alto-calendar draft since this draft has got aligned with
RFC7471,RFC7752 and ISIS-TE metric WG draft and ALTO-cost has been discussed several time and both draft are stable now.

[Qin]: I am wondering if we can have a timeslot in
> 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.

[Qin]: I hope not, I think ALTO is a just query protocol, but it follows RESTFUL approach and design, Use JSON to encode request and response, JSON provides encoding format.
yes we can use JSON to represent policy, but how JSON based policy is different from YANG based policy? I think YANG serves as both information model and data model therefore, when we model policy using YANG, it can be automatically generated into JSON based policy using some tool.

Clearly, the emergence of YANG has stymied the efforts of certain work items in ALTO.  

[Qin]: I think the big difference between them is ALTO separates schema from data model while YANG integrates schema into data model. 
YANG based model can be translated into JSON format, but for ALTO, given their difference, ALTO doesn't need to rely on YANG to generate JSON format, instead, it can generate JSON format directly.

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

[Qin]: There is a draft in NETMOD to discuss JSON Encoding of Data Modeled with YANG
https://tools.ietf.org/html/draft-ietf-netmod-yang-json-09
However I believe this JSON encoding rule defined in draft-ietf-netmod-yang-json-09 may not sufficient to support ALTO data.
It will be great for us to find gap between JSON encoding rule in draft-ietf-netmod-yang-json-09 and JSON encoding rule used in ALTO and document them.

Cheers,

- vijay

---

From: Qin Wu <[email-masked]>
Date: Sat, 26 Mar 2016 02:31:11 +0000

发件人: 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,

Hi, Vijay:

We authors plan to revive alto te metric draft and keep on proceeding
it in the upcoming IETF meeting.

Good.

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.

Cheers,

- vijay

Regards,
Kai