Hi all, As Rich has posted the new version, we would like to get a discussion started on extending the ALTO base protocol. The objective of this email is to get the discussions started. I will throw a few directions. These are, by intention, to be highly incomplete, but to get the discussion started.
[Topo]: An example new service is to extend the "single-switch" my-Internet-view topology model in the base protocol to provide a general topology service, to include more topology details. There is nothing wrong with the single-switch abstraction, and many recent SDN designs adopted this abstraction as well, indicating the value of this abstraction. But we do see use cases where less aggregation can be useful, and a good, general topology service can be an important component of the network/application north bound API. As one academic person, I found this problem highly interesting, rich, and useful. Any of your comments on this perspective can be highly valuable, and please do share your thought on either it makes sense, or not. [WritableALTO]: Another direction is to make "writable" ALTO. As we stated in the base protocol, the current spec is a unidirectional interface of information flow only from network applications. How about we provide some writable capabilities? Reinaldo and I had started the discussion along this direction. As a concrete example. The current spec has an endpoint property service, which a client can query the bandwidth of an endpoint. How about we make it writable, with the semantics that the client essentially requests that its end bandwidth be changed? This can be a highly valuable service. At the same time, it can have its challenges in defining its semantics. As a simple example, is it end to end? What is the scope (flows) of the request? Please share your comments or thinking. [Notification/subscription] There were good previous discussions on incremental updates, notifications, and subscriptions. I feel that it is time to revisit the topic, even in the context of application/network north bound API. Personally, I feel that this will be a great addition to ALTO, to make ALTO a better protocol serving as the API between applications and networks. If you have any thinking on organizing our efforts, both at the IETF meeting and before/after the meeting, please share your thinking as well, so that we can get the planning started. Thanks! Richard
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
