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 [email protected] https://www.ietf.org/mailman/listinfo/alto
