Subject: [altoext] resource reservation requests

From: David Harrington <[email-masked]>
Date: Fri, 09 Mar 2012 15:12:51 -0500

Hi,

<with AD hat off, or at least askew ;-)>

In my eyes, this would be outside the scope of ALTO.
ALTO is a passive information "exposure" protocol.
You could argue it is something of a network **monitoring** protocol, but
it deliberately has limited scope of applicability, and it is designed to
pass very limited information about the network state. So as a network
monitoring protocol, it has much less applicability than protocols like
SNMP, syslog, and ipfix.

To make ALTO an active cross-layer resource request protocol, I think you
would be changing ALTO to be a network **management** protocol.
That means the work probably belongs in the "management" side of the
Operations and Management area, not APPS, not TSV.
So I predict (c) will likely be considered out of scope for future ALTO
extensions.

Unless, of course, the ALTO community decides they would like to be a
network **management** protocol like SNMP or NETCONF or COPS-PR.
Being a network management protocol or resource reservation protocol has
lots of additional requirements that ALTO may not meet.
For example, network mgmt protocols require strong security -
authentication, authorization, integrity checking, replay prevention, DoS
mitigation, etc.
Network mgmt protocols must deal with issues (often encountered during
reboot), such as configuration persistence, and counter discontinuities.
Network mgmt protocols must deal with access controls at the user level -
who is allowed to perform what operations to what configuration data, etc.
Network mgmt applications must deal with limited CPU, memory, and storage
on devices such as routers and bridges and blades.
Network mgmt applications must deal with contention for CPU cycles;
traffic forwarding is more important than monitoring interface
performance, so network management protocols should be designed to put a
limited burden on a device's resources.
Network mgmt protocols must deal with coexistence - what happens if two
different applications try to reserve the same bandwidth?
What if one application is using ALTO, the other is using NETCONF or SNMP
or a CLI command? Who wins? Which gets saved to NV-RAM?
These are issues well known in the OPS area. I think they are less
important in the normal host environment where applications run.

I think the alto community would have an uphill battle arguing that alto
should become a cross-layer resource reservation protocol.

I recommend the i2aex community be acquainted with
draft-ietf-opsawg-management-stds-05
<http://datatracker.ietf.org/doc/draft-ietf-opsawg-management-stds/>,
"An Overview of the IETF Network Management Standards"

dbh

--

Greg,

> 2.    A Network Resource Reservation Interface - Where the "application"
>can
> make explicit requests for bandwidth between client regions and data
> centers.  This is  something kind of new conceptually for ALTO, but not
>from a
> protocol perspective, i.e. would use PID concepts and a RESTful service
> interface.
Is this not quite beyond ALTO in the sense that ALTO (so far, even with
the proposed extensions) is supposed to be passive, i.e. the ALTO client
gets information from an ALTO server (even if the server can notify the
client that there is new information, this is the case). I wonder if we
are targeting the kind of active requests you are describing, where the
ALTO client can "request" something from the server other than information.

--
David Harrington
Director, Transport Area
Internet Engineering Task Force (IETF)
[email-masked]
+1-603-828-1401