Subject: [alto] ALTO extension discussion?

From: "Y. Richard Yang" <[email-masked]>
Date: Sun, 14 Jul 2013 14:59:03 -0400

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

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 15 Jul 2013 19:09:56 +0000

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
>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 15 Jul 2013 23:21:44 -0400

Hi Michael,

> I am not sure if I understand the "single-switch" example. Do you think of

I am thinking of an abstract switch, neither L2 nor L3. It considers the
whole network as a single node.

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

Using MAC is a good topic that we should discuss more.

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

I consider RSVP, PCE as south bound API. What I was thinking is that ALTO
provides the north bound API, i.e., Restful calls that an app can call. It
will be mapped to south bound API (in addition to RSVP, .. but also Radius,
Diameter...).

>
> 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.
>
>
Very interesting idea. It is a simple, easy-to-manage access control
mechanism. I was thinking that we may be able to provide more general
access control, allowing expanding instead of only in the "slice".

> 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 ;)
>
>
Great to hear it. When we get the base protocol out of the door, I am
looking forward to working more on extensions.

Thanks!

Richard