Y. Richard Yang
2018-06-22 04:58:20 UTC
Dear all,
It is 24 days to the scheduled ALTO session, on July 16. After this
weekend, it will be only 3 weeks. During the last couple of months, to
better prepare for the coming IETF, some of us (Danny, Dawn, Lyle, Jensen,
Sabine, Shawn, Qiao, Christian) looked at both the current state and the
pipeline of ALTO.
For the current-state part, Dawn/Danny/Shawn are doing a wonderful review
of ALTO, on ALTO implementations, ALTO in related work. They will continue
to lead the efforts.
The objective of this email is to start a thread to discuss the pipeline
aspect. We want to discuss items that are not working group documents but
have interests. We may or may not have a chance to work on these items, but
will definitely help to get the discussion started.
At a high, rough level, we can classify ALTO pipeline into three
categories, and in each category, we can identify several potential working
items. At the end of this email is a list. We are hoping that we can have a
good discussion on this before and during the coming IETF.
Cheers,
Richard, on behalf of Danny, Dawn, Lyle, Jensen, Sabine, Shawn, Qiao,
Christian
*- App use cases/requirements/architecture 1. A systematic study of how
ALTO info be integrated/utilize in orchestration1. One aspect ALTO + PCE,
ABNO, Path-based, 2. Extension to new architectures (e.g., cellular, 5G)
endpoint types3. Extension to new settings such as multi-domain (ALTO is
traditional design for App-Net, i.e., north-south interface, interdomain is
more EW interface), SFC, NFV, edge clouds- API/base protocol 1. A general
multipart service, SSE -> HTTP/22. Flow cost service, extensible query
schema for a set of flows, may including unicast and multicast, multipath,
....3. Calendar for endpoint entity properties [Sabine]4. Unified resource
representation (e.g., mathematical programming representation abstraction,
linear inq)- Backend/infrastructure 1. Smart/on-demand measurements (query
miss trigger, start and collect measurements, formalize the protocol,
connect to IPPM, accuracy/freshness, what kind of info to be provided)2.
Proxy architecture, for scale, interdomain, for fault tolerance, for
security/privacy*
It is 24 days to the scheduled ALTO session, on July 16. After this
weekend, it will be only 3 weeks. During the last couple of months, to
better prepare for the coming IETF, some of us (Danny, Dawn, Lyle, Jensen,
Sabine, Shawn, Qiao, Christian) looked at both the current state and the
pipeline of ALTO.
For the current-state part, Dawn/Danny/Shawn are doing a wonderful review
of ALTO, on ALTO implementations, ALTO in related work. They will continue
to lead the efforts.
The objective of this email is to start a thread to discuss the pipeline
aspect. We want to discuss items that are not working group documents but
have interests. We may or may not have a chance to work on these items, but
will definitely help to get the discussion started.
At a high, rough level, we can classify ALTO pipeline into three
categories, and in each category, we can identify several potential working
items. At the end of this email is a list. We are hoping that we can have a
good discussion on this before and during the coming IETF.
Cheers,
Richard, on behalf of Danny, Dawn, Lyle, Jensen, Sabine, Shawn, Qiao,
Christian
*- App use cases/requirements/architecture 1. A systematic study of how
ALTO info be integrated/utilize in orchestration1. One aspect ALTO + PCE,
ABNO, Path-based, 2. Extension to new architectures (e.g., cellular, 5G)
endpoint types3. Extension to new settings such as multi-domain (ALTO is
traditional design for App-Net, i.e., north-south interface, interdomain is
more EW interface), SFC, NFV, edge clouds- API/base protocol 1. A general
multipart service, SSE -> HTTP/22. Flow cost service, extensible query
schema for a set of flows, may including unicast and multicast, multipath,
....3. Calendar for endpoint entity properties [Sabine]4. Unified resource
representation (e.g., mathematical programming representation abstraction,
linear inq)- Backend/infrastructure 1. Smart/on-demand measurements (query
miss trigger, start and collect measurements, formalize the protocol,
connect to IPPM, accuracy/freshness, what kind of info to be provided)2.
Proxy architecture, for scale, interdomain, for fault tolerance, for
security/privacy*