Hi all,



Below are some thoughts on the overlay/underlay integration discussion. Please 
see details inline.




Kai



-----Original Messages-----
From:"Qin Wu" <bill...@huawei.com>
Sent Time:2021-03-11 15:55:31 (Thursday)
To: "Jensen Zhang" <jingxuan.n.zh...@gmail.com>
Cc: "alto@ietf.org" <alto@ietf.org>
Subject: Re: [alto] Bringing operation automation cases to the list



Hi, Jensen:

发件人: Jensen Zhang [mailto:jingxuan.n.zh...@gmail.com]
发送时间: 2021年3月11日 15:39
收件人: Qin Wu <bill...@huawei.com>
抄送: Y. Richard Yang <y...@cs.yale.edu>; LUIS MIGUEL CONTRERAS MURILLO 
<luismiguel.contrerasmuri...@telefonica.com>; alto@ietf.org
主题: Re: [alto] Bringing operation automation cases to the list

 

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.

 

[Qin]: Good point, this is chicken-egg problem.:-)

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.

[Qin]: IETF Dyncast side meeting last night investigate what metric should be 
defined, how frequent the update is, I think probably also related to this 
issue. I think ALTO can provide a solution for compute information exposure if 
we look for centralized solution.

 

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.




[KAI] When Jensen said "overlaps with the pub/sub item", my understanding is 
that the integration is a closed-loop such that the overlay may alter its 
demands/subscriptions based on ALTO information received from the underlay, and 
the underlay also somehow subscribes to those demands and may return different 
information accordingly.





[KAI] My first reaction is "Isn't this how pub/sub works in ALTO?" if demands 
simply represent subscriptions from an ALTO client. Or maybe the demands can be 
something that is not defined in the current ALTO documents/extensions? In that 
case, I think it would be helpful to first clarify the integration problem 
here: what capabilitybeyond existing ALTO extensions is essential to enable 
such kind of integration?





[KAI] I do see that the overlay/underlay integration is closely related to 
operation automation and data model, especially in the case where both underlay 
(ALTO server) and overlay (ALTO client) belong to the same administrative 
domain.





And we should also better clarify the goal (to deliver either an experience 
document or a standard document).

[Qin]: I assume you are asking whether we should document this item as BCP or 
standard track, or experimental, I am not worried about its overlapping with 
pub sub item, BCP can document the best practice, which is not necessary to 
introduce any protocol extension.




[KAI] I agree that a document is essential.




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

Reply via email to