Hi all, Please see my comments inline.
On Thu, Mar 11, 2021 at 2:38 PM Qin Wu <bill...@huawei.com> wrote: > Hi, Richard: > > *发件人:* alto [mailto:alto-boun...@ietf.org] *代表 *Y. Richard Yang > *发送时间:* 2021年3月11日 12:52 > *收件人:* LUIS MIGUEL CONTRERAS MURILLO < > luismiguel.contrerasmuri...@telefonica.com> > *抄送:* alto@ietf.org > *主题:* Re: [alto] Bringing operation automation cases to the list > > > > Hi Luis, > > > > Good summary. Please see below. > > > > On Wed, Mar 10, 2021 at 5:18 PM LUIS MIGUEL CONTRERAS MURILLO < > luismiguel.contrerasmuri...@telefonica.com> wrote: > > Hi all, > > > > Apologies for the time taking to post the operation automation cases to > the list. > > > > As part of the re-charter discussion, four use cases will be considered > for supporting the proposal in which respect to ALTO extensions for > operation automation. > > > > Case 1. Extensions to RFC 7971 leveraging on previous protocol extensions > (e.g., cost calendar, path vector) that can make necessary new > architectural and deployment considerations > > > > RFC7971 is valuable and hence an update to include the effects of protocol > extensions is highly valuable. I understand that cost calendar and path > vector are examples, and other extensions such as SSE can be included and > we want to make sure to do a relatively comprehensive update. > > [Qin]: Another limitation of RC7971 is to lack multi-domain support. > Therefore I feel multi-domain support should be also documented for this > item to address limitation of ALTO deployment in RFC7971. > Yes, multi-domain support can be also considered. But we need to clarify the limitation of existing deployment considerations for multiple-domain cases in RFC7971 (e.g., cascaded servers). To compare with the well-specified extensions like cost calendar, path vector, and SSE, one concern is that the multi-domain support may involve new extensions which have not been well specified yet. > Case 2. Usage of ALTO for combined compute and network selection (e.g., > for optimal edge computing service placement). > > > > Does Case 2 belong to general protocol extension or operation automation? > > [Qin]:I think operation automation is also required in this case, i.e., > how network information and compute information are aggregated. One thing I > am not sure is whether > > Whether path vector has already supported compute information? Maybe > author can clarify. > The path vector extension itself doesn't support compute information. I assume you are talking about the entity property map. I think we can leverage the entity property map to expose the compute information by defining new entity domains and property types systematically (like what the performance cost metrics document does). But we need to dig into real use cases to see if anything is missing. But beyond the protocol extension, I'm also interested in how to collect those compute information from an operator's view. It will also affect the data model work. > > > Case 3. Extensions to ALTO for acting as aggregator of information from > different sources (e.g., TEDB, LSP DB, etc) > > > > Case 3 is definitely a good use case supporting operation automation. > > > > Case 4. Overlay / underlay integration supported by ALTO (e.g., CDN). > > > Overlay/underlay integration can have many aspects. So the goal is to > focus on the operation automation aspect? One possibility is to define > operation automation broadly, including operation automation of not only > ALTO but the overall system (i.e., the integrated overlay/underlay). If > this is the case, we may want to specify the scope well. > > [Qin]: Agree, I think this case describe ALTO interface as Network as a > service interface, allow the underlay expose capability and status to the > overlay, So overlay can know how to optimize the service delivery. This > case looks very interesting. > I think not just the underlay can expose info to the overlay, the overlay can also express its fine-grained demand and subscribe info to the underlay. It may have some overlaps with the pub/sub item. We may need more clarification about the integration solution. And we should also better clarify the goal (to deliver either an experience document or a standard document). Thanks, Jensen > Looking forward to a great discussion on Friday. > > > > Richard > > > > Any comment, suggestion or indication is more than welcome. > > > > Thanks > > > > Luis > > > > __________________________________ > > Luis M. Contreras > > > > Technology and Planning > > Transport, IP and Interconnection Networks > > Telefónica I+D / Global CTIO unit / Telefónica > > > > Distrito Telefónica, Edificio Sur 3, Planta 3 > > 28050 Madrid > > España / Spain > > > > Skype (Lync): +34 91 312 9084 > > Mobile: +34 680 947 650 > > luismiguel.contrerasmuri...@telefonica.com > > > > > > > ------------------------------ > > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, > puede contener información privilegiada o confidencial y es para uso > exclusivo de la persona o entidad de destino. Si no es usted. el > destinatario indicado, queda notificado de que la lectura, utilización, > divulgación y/o copia sin autorización puede estar prohibida en virtud de > la legislación vigente. Si ha recibido este mensaje por error, le rogamos > que nos lo comunique inmediatamente por esta misma vía y proceda a su > destrucción. > > The information contained in this transmission is privileged and > confidential information intended only for the use of the individual or > entity named above. If the reader of this message is not the intended > recipient, you are hereby notified that any dissemination, distribution or > copying of this communication is strictly prohibited. If you have received > this transmission in error, do not read it. Please immediately reply to the > sender that you have received this communication in error and then delete > it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, > pode conter informação privilegiada ou confidencial e é para uso exclusivo > da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário > indicado, fica notificado de que a leitura, utilização, divulgação e/ou > cópia sem autorização pode estar proibida em virtude da legislação vigente. > Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique > imediatamente por esta mesma via e proceda a sua destruição > > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto > > > > > -- > > -- > > ===================================== > > | Y. Richard Yang <y...@cs.yale.edu> | > > | Professor of Computer Science | > > | http://www.cs.yale.edu/~yry/ | > > ===================================== > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
