Re: [alto] ALTO extension discussion?

["Scharf, Michael (Michael)" <[e-mail]>]

Hi Richard, 

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

I am not sure if I understand the "single-switch" example. Do you think of a L2 or L3 network?

As far as I can tell, ALTO is pretty powerful for describing L3 topologies, even if improvements are possible, cf. the various existing drafts on extensions.

Using L2 (MAC) addresses in ALTO is possible, but raises a lot of questions as well. We have some discussion on MAC addresses in draft-scharf-alto-vpn-service-01 (albeit in a special context).
 
> [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.

Are you talking here about bandwidth-on-demand, i.e., that the bandwidth provisioned by the ISP is indeed changed using the ALTO interface? This would be a complex use case. There are several protocols for such BW reservations already (e.g., RSVP, NSIS, PCE...), and it is non-trivial to get them deployed in a real network.

But there is an interesting use case on WritableALTO: Let's assume that an ISP announces the provisioned access network bandwidth by means of ALTO. Furthermore, a customer may want that the ALTO server only announces a *fraction* of the actual provisioned bandwidth (let's say, 50%), to have headroom for applications not using ALTO guidance (this is not about congestion control!). Then, the client may want to configure that parameter in the ALTO server. This is a write option. But as long as the parameter is smaller than the provisioned bandwidth (e.g., 0%..100%), it does not require any RSVP-like action. This kind of operation would require a simple, standardizes ALTO write interface between client and server. I believe that such an ALTO extension would not be overly complex.

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

Yes, indeed. draft-schwan-alto-incr-updates-02 will expire tomorrow, but we plan to resubmit it once a discussion about such ALTO extensions is allowed ;)

Michael


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