If ALTO doesn¹t take up some of these items, at least, I fear much of the work to date may be for nought. We need 3, 4 and 5 for ALTO to be a credible CDNi solution, for example. So yes, I would urge the group to take up these work items. We can debate the priority among them, but let¹s get them chartered and done.
Jon Peterson Neustar, Inc. On 1/23/14, 11:11 AM, "Vijay K. Gurbani" <[email protected]> wrote: >Folks: Over the last few IETFs, Enrico and I have solicited feedback >during face-to-face meetings, WG sessions, hallway conversations, ALTO >mailing list and private conversations on how to move ahead with respect >to adopting new work items. > >As we begin the charter discussions, we have identified seven >work items to propose as additions to the charter. The first four of >these work items are fairly uncontroversial. The last three are work >items that have a monumental mind share in the ALTO working group and >have been found to be extremely useful in controlled networks (e.g., >VPNs). However, we have to take some care in defining these such that >we do not duplicate the functionality available elsewhere (e.g., general >routing) in ALTO, nor do we take on an aspect that the working group >does not fully understand. > >Here are the seven items up for discussion: > >1. Anycast-based server discovery > (Presented by Reinaldo Penno in IETF 86 and appears to have > some support for adoption.) > >2. Third-party server discovery > (Sebastian Kiesel et al. have been driving this work and it > also appears to have support.) > >3. Incremental ALTO map updates > (Side meeting held during IETF 86; two proposals have been > studied. One way forward is to use an ALTO-specific incremental > update that may be more efficient, and the second approach is to > simply use JSON patch.) > >4. Server-initiated update notifications > (Jan Seedorf and Enrico Marocco have suggested the use of > Websockets; HTTP/2.0 may provide some mitigation as well.) > >5. Extensions to annotate PIDs with properties (e.g., geographical > locations). > (Useful as an extension in controlled environments, e.g., VPNs > where IP addresses are not the only form of identification. > Some drafts, including draft-roome-alto-pid-properties > has already started work in this direction.) > >6. Extensions for cost metrics. > (Some drafts, including draft-wu-alto-json-te, have started work > in this direction.) > >7. An ALTO format for encoding graphs. > (draft-ietf-alto-protocol already recognizes the need to provide > topology details that are useful in controlled environments. > Richard Yang, Greg Bernstein and others have been working on the > need and use cases for such an encoding. draft-yang-alto-topology > is a good start. Projects like OpenDayLight and NetworkX (Python) > have JSON models for graph representation. Some concrete examples > of how we envision encoding graphs will be useful during list > discussion.) > >We will like to understand whether the working group believe such >additional deliverables, if included in an updated charter proposal, >would allow people to do the extension work that has been repeatedly >proposed. (Clarification: we are explicitly asking whether people could >find such an update acceptable. We understand that anyone will have a >preferred flavor of the above.) > >We are at a point where show of support by whoever is interested is >essential for moving forward. If it turns out to be positive, Enrico >and I will subsequently circulate actual text, including milestones, for >a rechartering request. > >Thanks. > >- vijay >-- >Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) >Email: vkg@{bell-labs.com,acm.org} / [email protected] >Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq >_______________________________________________ >alto mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
