------------------------------ - *From*: "Reinaldo Penno (repenno)" <repenno at cisco.com <[email protected]>> - *To*: "Peterson, Jon" <jon.peterson at neustar.biz <[email protected]>>, "Vijay K. Gurbani" <vkg at bell-labs.com <[email protected]>>, alto <alto at ietf.org <[email protected]>> - *Date*: Mon, 27 Jan 2014 22:26:23 +0000 - *In-reply-to*: <cf0bd3fc.d2cca%[email protected] <http://www.ietf.org/mail-archive/web/alto/current/msg02360.html>>
------------------------------ 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. [Qin]:I fail and am confused to see first 4 items not extensions or enhancements. I see service orientated infrastructure has a lot of promising. Item 6 "ALTO Cost metrics extesion" does aim at that and provide various cost metric for different application, e.g., latency sensitive application,bandwidth sensitive application. [I.D-ietf-idr-ls-distribution] and [I.d-ietf-idr-te-pm-bgp] have already provided BGP extension to distribute TE information and network performance information to ALTO server, see figure 3 of [I.D-ietf-idr-ls-distribution] and figure 2 of [I.d-ietf-idr-te-pm-bgp]. These information can be collected and aggregated by ALTO server using routing protocol (see figure 1 of ALTO base protocol) and can be used in the same way as routingcost metric. This information doesn't need to disclosed as output to application but as constraint based on policies and rules set by the operator and allows application to connect better endpoint. item 6 just adds a few addtional cost metric and is not a big work. >From this perspective, I could also say item 6 is more about a bug fixing. Thanks, Reinaldo On 1/27/14, 9:35 AM, "Peterson, Jon" <jon.peterson at neustar.biz> 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" <vkg at bell-labs.com> 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.)
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
