Support all 7. Greg On 1/23/2014 11:11 AM, Vijay K. Gurbani 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
-- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
