[alto] Starting the ALTO extension discussion

["Vijay K. Gurbani" <[e-mail]>]

Folks:

Enrico and I have put together some thoughts on how to direct our
energies into making sense of the ALTO extensions so we can reasonably
differentiate the extensions that are possible with the current base
ALTO protocol from those that may require an updated charter.

Here is the general extension taxonomy without resorting to listing each
extension draft; we hope this will guide the list discussions.

- Pub/sub (asynchronous notification) extension.

- Incremental updates. (Nominally, this is a subset of pub/sub, but the
   exact format for the incremental update needs to be agreed upon.  At
   hand are two methods to do incremental updates, one is using JSon
   Patch [RFC6902] and the other is through an ALTO-specific patch
   extension [draft-schwan-alto-incr-updates-02]).

- Property extensions (endpoint property and PID property) to aid in
   representing network attachments in terms other than IP addresses.
   For instance, the current charter notes that geographical distance
   could be used as network preference.  The extension related to
   VPN expresses network attachment points in terms of a geolocated
   URL.

- Topology based decision model extensions: moving from a "single
   node" network model to an topology model featuring link and node
   abstractions to facilitate end point and path selection guidance.

- Cost metric extensions: moving beyond the base "routingcost" metric.

We think that the above five buckets subsume most of the mature
extension drafts that we saw presented at Vancouver and before that,
Berlin and Orlando.

The first three extensions are fairly easy to reason about.  The first
two are agreed upon by many, and the third one (property extension) can,
we believe, be supported through the ALTO address type registry
mechanism defined in the base draft (http://tools.ietf.org/html/draft-
ietf-alto-protocol-20#section-14.4). The discussion we expect to have
on the list regarding property extension is whether the registry fits
our needs or whether we need to do something more.

Similarly, we believe we generally know what we want from the topology
reasoning extension, but we should discuss the exact nature of this on
the list.  For example, do we want to represent links and transit points
in a multi-switch topology?  What sort of graph transformations to raw
network information do we intend to apply?  It will not suffice to say
simply that we intend to do so, we need to be more granular now and say
*how* we intend to do so.

Regarding the cost metrics, in draft-wu-alto-te-metrics, there are
certain cost metrics like delay, delayjitter and pktloss, that do not
need the WG to do anything special beyond documenting these in an I-D,
having an Expert Review before IANA adds these to the ALTO Cost metric
registry (c.f. http://tools.ietf.org/html/draft-ietf-alto-protocol-
20#section-14.2).  No extensions needed here.

However, in the same draft (draft-wu-...) there are other metrics like
maxbw and maxreservbw that define a new ALTO object type.  We would need
to figure out how to handle this new type, especially since it requires
an update to the filtering mechanism.  It is, at the very least, worth
having a discussion on the list on what type (if any) extension
mechanism would be needed here.

We will like to start a larger dialogue in the working group to
determine the next steps in the direction of moving ALTO ahead.

Proponents of individual extensions should note:

   1. Where in the above taxonomy their extension fits in.
   2. Whether the base protocol supports the said extension?
      a. If yes, what is needed to get the extension moving, i.e.,
         consensus on list that the extension is of importance,
         an expert review required (see Section 14 of the ALTO
         protocol).  Maybe we term these as "simple" extensions.
      b. If no, gather consensus on the mailing list for these
         "complex" extension and determine how to approach a
         solutin space.

As was mentioned in the Vancouver meeting, the working group interest
in extensions and the capability of a core set of people to commit to
seeing the extensions through will inform what extensions can now
proceed as the base protocol matures.

So, let's go at it and see where we arrive before the London IETF.

Thanks,

Vijay K. Gurbani and Enrico Marocco