ALTO WG, 89th IETF, London, UK. Thursday, Marh 6 2014 1520-1650 Balmoral Suite Scribes: Jan Seedorf, Diego Lopez Jabber: Dhruv Dhody Attendees: 55 Enrico goes through the agenda: deployment consideration discussion followed by the charter discussion. The charter discussions have been proceeding for months; we have draft charter text now and we will like to see if the room thinks what is proposed is acheivable in reasonable time. Status of the working group: The ALTO protocol draft has been approved by the IESG! (Yay!). Thanks to the editors and everyone who contributed to the process. Deployment considerations (presented by Michael Scharf) Michael went through the summary of changes (slide 2). Some discussions have taken place on "Monitoring ALTO" (slide 3), mostly driven by the performance directorate who asked for this. Discussion between Qin Wu and Michael on the monitoring infrastructures in large-scale operator networks. The section may still need more work. The document can be improved further, Michael does not think it is ready for WGLC. He wants to add some more sections and text before he feels the document can be advanced. He solicited input for additional ALTO use cases that can be added to Section 6. Enrico feels that the document is in good shape and provides good deployment information to service providers. After the revision by Michael, the documnet should be allowed to move forward. Charter Update Vijay notes that many extensions have been proposed for the last two years but were gated by the readiness of the ALTO protocol. There have been at least 15 individual drafts spread across four broad categories of extensions (protocol optimizations, server discovery, endpoint property and e2e cost, graph representation). Clearly, a mass of interested people exists on breaking new ground beyond the base protocol. Each category of extension was discussed in turn. Protocol optimization extensions -------------------------------- Looking at two things: server initiated connections and incremental updates. There are several strawman proposals on server initiated connections as well as incremenal updates. CDNI needs incremental updates. Floor opened up for discussion on this. Jan Seedorf notes that it is too early to comment on what is the best mechanism to achieve server initiated and incremental updates. But, what is of more importance here is that this category must be on the charter since many use cases will benefit from this. Martin Stiemmerling urged people to express interest in this item. Michael Scharf supports adding this to the charter, as did Jon Peterson. Jon's fear is that we have quelled energy on this and we should quickly get to a resolution on what the right way to do server-initiated connections and incremental updates. Darryl Malas agrees that the incremental update piece is something that the CDNI WG is interested in, whether or not ALTO is the right transport is yet to be determined. Sebastian Kiesel supports this as a charter item as well. Wendy Roome (remote) indicates support. Richard Yang notes that his group at Yale is interested as well. Vijay notes that on the balance no one disagrees that this category should be a chartered extension. This has been true on the list as well. Enrico asked how many people will be interested in contributing (writing drafts) on protocol optimizations. A show of hands was asked and indicated about 8-10 people who will actively contribute. Server discovery extensions --------------------------- Base ALTO server discovery has been done (in RFC Editor's queue). Current mechanisms are for third-party and anycast-based server discovery. Vijay sought discussion on an anycast-based discovery and third- party discovery. Enrico notes that these drafts are fairly mature and this work completes the existing server discovery work item. Jon Peterson raised the issue whether anycast-discovery belongs here. Martin Stiemmerling agrees that anycast- and third-party discovery is broader than ALTO. Question is who does it? There is some thinking that a general server discovery mechanism should involve a BoF first to determine people of interest and expertise to do this work. Martin Stiemmerling (not as AD) suggested that maybe having text (but not a milestone) stating that ALTO will use to-be-developed server discovery mechanisms may be all that is needed. Spencer Dawkins (as AD) noted that putting this as a milestone is fine since it will precipitate an IESG discussion on the broader issue of server discovery (which, apparently, other folks are looking at as well). The participants appeared to coalesce on putting text in the charter on third party server discovery, but not assingning a milestone. It will be stated that ALTO needs third-party server discovery, and if no one else will look into a general method for third-party server discovery, then ALTO will look into a specific mechanism fit for ALTO. Spencer will then use this to further the cause of the larger context of third-party server discovery in the IESG. Sebastian Kiesel thinks that what is there in current ALTO third- party server discovery is fairly general enough. Maybe sending that document elsewhere is fine, but where? Sebastian notes that this was an important issue in the Bittorrent / Comcast debate, where third party ALTO server discovery was very useful. Vijay stated that with ALTO being adopted by other use cases (CDN, DC) the original impetus to have third-party server discovery may no longer be as acute. Endpoint property and e2e cost extensions ----------------------------------------- There have been proposals to use ALTO for DC and CDN use cases. The extensions here not only provide for "where" to connect, but also "when" to connect. Other characteristics here that are useful are attributes related to, say, the links and servers in the DC and CDN centers. Because there are other WGs (CDNI, I2RS) that are operating in an interesection of this space, work will be coordinated with them to ensure no duplication. Vijay started discussion on draft on PID properties, which is currently structured around an inheritance model. Jan Seedorf notes that inheritence is not a necessary artifact for use of PID properties in CDNI, but assiging discrete properties to PIDs is of importance to CDNI. Jan Seedorf outlined CDNIs FCI interface where a downstream CDN provides information to upstream CDN about its footprint (geographical coverage) and capabilities (delivery protocols it supports, for example). PID properties allow for a clean separation of footprint and capabilities. A recent alternative to Jan Seedorf's draft is the thinking that the FCI object should be standardized in CDNI while ALTO is used for transporting the object. Darryl Malas (co-chair of CDNI) expressed some trepidation on using CDNI as a motivation for chartering an endpoint property extension. Jon Peterson noted that there was a hum in CDNI to proceed with a CDNI-standardized FCI object transported in ALTO. Darryl agrees but also notes that there was some discussion that if ALTO did not suffice as the transport option, others will be looked at in CDNI. Jan Seedorf and Jon Peterson agree that irrespective of ALTO used as transport, the charter should not preclude new ALTO information service for CDNI FCI from being developed; the CDNI object will be specified in CDNI WG and the information service itself will be in ALTO. Chairs put up the draft charter extension related to endpoint property and end-to-end cost extensions. Reasonable amount of discussion ensued on whether or not working groups to liaise with should be named on the slide. Darryl Malas felt strongly that CDNI should be removed. Ted Hardy suggested that the names of the WGs be removed from the charter text and a new sentence be added to the last paragraph that says "The scope of extensions is not limited to those identified by the WGs." Vijay went through other motivations for endpoint property extensions (VPNs) and end-to-end cost extensions. Michael Scharf notes that these extensions are low-hanging fruit, just do it. Graph representation extensions ------------------------------- Today, an ALTO cost map is an nxn matrix of PIDs with the weights representing the cost. Techniques to formalize the structure of a network graph and represent this in some encoding format is a reasonable goal to achieve. We can go beyond a survey of graph representation models if there is interest and people willing to work on a representation format. Specifically, simple extensions generalizing ALTO cost maps to provide for both path-vector and node-edge representations to be provided to the client for appropriate path computation. Young Lee reminded the WG that the early motivation for graph representation was DC selection, especially to provide an abstract view (not a full graph) to allow operators to avoid bottleneck links. He supports this work. Jan Seedorf sees use cases for this work, but worries about the complexity. Does not mean that we should not do it, but rather make sure we are aware of corner cases, etc. Michael Scharf supports doing the survey as well as moving beyond the survey and doing the graph representation itself. Today ALTO can support client-specific views, but with graph representation it may not have to. It simply sends an abstract notion of the network graph and the client decides how to reach the destination. This is certainly a larger extension than others but most definitely worthwhile to do. Jon Peterson supports doing the survey and moving beyond it to allow ALTO to represent topologies. Jan Medved notes that the work to represent a network topology has been done using Yang in OpenDaylight and extracted using restconf. In Jan's mind, Yang and restconf is the way to go. Robert Varga suggests not defining an representation until the Yang information model is adopted in I2RS WG. Alia Atlas suggested that ALTO should continue to build on its strength of abstraction, summarizing and providing a way of sharing information across administrative boundaries. ALTO should take the work in I2RS on Yang information modeling and use that in the context of its strengths. Sebastian Kiesel does not understand what is the role for ALTO between information model and the RESTCONF transport. He believes it needs more study. Michael Scharf notes that ALTO is about abstract information that shields from the underlying network routing protocols. Also, restconf is a complex network management protocol, ALTO is a simple JSON-based protocol. We are not interested in having a full restconf client in every ALTO client. Meeting adjourned with the note from chairs that they will digest this information and be in touch with the list and the AD on next steps.