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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/alto > -- -- ===================================== | Y. Richard Yang <[email protected]> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =====================================
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
