Minutes for ALTO at IETF-89
minutes-89-alto-1

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.