Re: [alto] Starting the ALTO extension discussion

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

Hi Vijay, Enrico,

Thanks for posting the thoughts on ALTO extensions! Should we reply to this
email, or start a separate thread for each extension to answer the
questions?

Richard


On Mon, Nov 18, 2013 at 2:45 PM, Vijay K. Gurbani <[e-mail]> wrote:

> 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
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>



-- 
-- 
 =====================================
| Y. Richard Yang <[e-mail]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================