Re: [alto] ALTO extension discussion?

["Y. Richard Yang" <[e-mail]>]

Hi Michael,

On Monday, July 15, 2013, Scharf, Michael (Michael) wrote:

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

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.


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

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


> > [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 ;)
>
>
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


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