Agreed. I conveyed the same to the chairs offline but let me repeat here. 1 - ALTO as specified in draft-alto is something difficult to deploy in production.
2 - In other for ALTO to be a well-rounded, deployable, robust protocol we need to do the first 4 items. In other words, I believe the first 4 items are not extensions or enhancements, but the result of “bugs” that need fixing. 3 - Item 5 is something I think has great potential. If we could choose only one feature to include in the charter I would vote for number 5. Thanks, Reinaldo On 1/27/14, 9:35 AM, "Peterson, Jon" <[email protected]> wrote: > >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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
