[OPSAWG]Re: Sheperd write-up for for YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (draft-ietf-opsawg-teas-attachment-circuit)

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Joe, Med,

I concur that both references are not necessary for understanding or 
implementing the YANG module, so certainly should be categorized as informative.

I will update the write-up in consequence.

Best regards

Luis

PS. Thanks Med for the updates in the draft.

De: Joe Clarke (jclarke) 
Enviado el: miércoles, 29 de mayo de 2024 15:25
Para: mohamed.boucad...@orange.com; LUIS MIGUEL CONTRERAS MURILLO 
; opsawg@ietf.org
CC: draft-ietf-opsawg-teas-attachment-circ...@ietf.org
Asunto: Re: Sheperd write-up for for YANG Data Models for Bearers and 
'Attachment Circuits'-as-a-Service (ACaaS) 
(draft-ietf-opsawg-teas-attachment-circuit)

AVISO/WARNING: Este correo electrónico se originó desde fuera de la 
organización. No haga clic en enlaces ni abra archivos adjuntos a menos que 
reconozca al remitente y sepa que el contenido es seguro / This email has been 
originated from outside of the organization. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.

Thanks, Med.  Luis, can you re-review and adjust your shepherd write-up 
accordingly?

Joe

From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 
mailto:mohamed.boucad...@orange.com>>
Date: Wednesday, May 29, 2024 at 09:21
To: Joe Clarke (jclarke) mailto:jcla...@cisco.com>>, LUIS 
MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>,
 opsawg@ietf.org<mailto:opsawg@ietf.org> 
mailto:opsawg@ietf.org>>
Cc: 
draft-ietf-opsawg-teas-attachment-circ...@ietf.org<mailto:draft-ietf-opsawg-teas-attachment-circ...@ietf.org>
 
mailto:draft-ietf-opsawg-teas-attachment-circ...@ietf.org>>
Subject: RE: Sheperd write-up for for YANG Data Models for Bearers and 
'Attachment Circuits'-as-a-Service (ACaaS) 
(draft-ietf-opsawg-teas-attachment-circuit)
Hi Joe, Luis, all,

I agree with Joe's assessment for these refs. Submitted right now a new version 
to address the review from Luis.

As a bonus, also added another example to show how the model is powerful in 
covering another deployment case.

Cheers,
Med

De : Joe Clarke (jclarke) mailto:jcla...@cisco.com>>
Envoyé : mercredi 29 mai 2024 12:49
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>; LUIS 
MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>;
 opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc : 
draft-ietf-opsawg-teas-attachment-circ...@ietf.org<mailto:draft-ietf-opsawg-teas-attachment-circ...@ietf.org>
Objet : Re: Sheperd write-up for for YANG Data Models for Bearers and 
'Attachment Circuits'-as-a-Service (ACaaS) 
(draft-ietf-opsawg-teas-attachment-circuit)

Thank you, Luis for the review and for agreeing to act as shepherd.  I read 
through your write-up and this diff.  I see you called out the IEEE802.1AX and 
IEEE802.1AB references, but I do not see that addressed in this diff or 
discussed here.

I don't like sending up drafts that have identified or potentially identified 
issues if it can be avoided.  In my reading of this draft, I feel these IEEE 
standards are informative in that I don't need to understand them to be able to 
implement this YANG module.  It sounds like you feel differently, Luis?

Joe

From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 
mailto:mohamed.boucad...@orange.com>>
Date: Tuesday, May 28, 2024 at 04:48
To: LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>,
 opsawg@ietf.org<mailto:opsawg@ietf.org> 
mailto:opsawg@ietf.org>>
Cc: 
draft-ietf-opsawg-teas-attachment-circ...@ietf.org<mailto:draft-ietf-opsawg-teas-attachment-circ...@ietf.org>
 
mailto:draft-ietf-opsawg-teas-attachment-circ...@ietf.org>>
Subject: [OPSAWG]Re: Sheperd write-up for for YANG Data Models for Bearers and 
'Attachment Circuits'-as-a-Service (ACaaS) 
(draft-ietf-opsawg-teas-attachment-circuit)
Hi Luis,

Thank you for the review.

Please see a diff to track the changes at: Diff: 
draft-ietf-opsawg-teas-attachment-circuit.txt - 
draft-ietf-opsawg-teas-attachment-circuit.txt<https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-teas-attachment-circuit.txt_2=https://boucadair.github.io/attachment-circuit-model/boucadair-patch-5/draft-ietf-opsawg-teas-attachment-circuit.txt>.

Please let us know if any further change is needed.

See inline for more context.

Cheers,
Med

De : LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
Envoyé : lundi 27 mai 2024 16:55
À : opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc : 
draft-ietf-opsawg-teas-attachment-circ...@ietf.org<mailto:draft-ietf-opsawg-teas-attachment-circ...@ietf.org>
Objet : Sheperd write-up for for YANG Data Models for Bearers and 'Attachment 
Circuits'-as-a-Service (ACaaS) (draft-ietf-opsawg-teas-attachment-circuit)


Dear authors,

With som

[OPSAWG]Re: Sheperd write-up for for YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (draft-ietf-opsawg-teas-attachment-circuit)

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Med

Thanks so much for your prompt reaction. Your changes look perfectly fine to me.

Regarding your mail:

> The review is available here: 
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/shepherdwriteup/
>[Med] Thanks. I guess the writeup can indicate that this spec was presented to 
>TEAS and that it was WGLCed there as well. Thanks.
Luis >> Correct

> Figure 6, valid-provider-identifiers.
>[Med] Can you please clarify the comment here? Thanks.
Luis >> Sorry, I didn't complete the comment. It was about the usage of 
"valid". I would presume that all the provider identifiers are valid, or in 
other words, that not valid indertifiers are never used. Sounds weird to me the 
usage of "valid" but that can be subjective. I forget to remove it.

Thanks again,

Best regards

Luis



De: mohamed.boucad...@orange.com 
Enviado el: lunes, 27 de mayo de 2024 19:27
Para: LUIS MIGUEL CONTRERAS MURILLO 
; opsawg@ietf.org
CC: draft-ietf-opsawg-teas-attachment-circ...@ietf.org
Asunto: RE: Sheperd write-up for for YANG Data Models for Bearers and 
'Attachment Circuits'-as-a-Service (ACaaS) 
(draft-ietf-opsawg-teas-attachment-circuit)

AVISO/WARNING: Este correo electrónico se originó desde fuera de la 
organización. No haga clic en enlaces ni abra archivos adjuntos a menos que 
reconozca al remitente y sepa que el contenido es seguro / This email has been 
originated from outside of the organization. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.

Hi Luis,

Thank you for the review.

Please see a diff to track the changes at: Diff: 
draft-ietf-opsawg-teas-attachment-circuit.txt - 
draft-ietf-opsawg-teas-attachment-circuit.txt<https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-teas-attachment-circuit.txt_2=https://boucadair.github.io/attachment-circuit-model/boucadair-patch-5/draft-ietf-opsawg-teas-attachment-circuit.txt>.

Please let us know if any further change is needed.

See inline for more context.

Cheers,
Med

De : LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
Envoyé : lundi 27 mai 2024 16:55
À : opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc : 
draft-ietf-opsawg-teas-attachment-circ...@ietf.org<mailto:draft-ietf-opsawg-teas-attachment-circ...@ietf.org>
Objet : Sheperd write-up for for YANG Data Models for Bearers and 'Attachment 
Circuits'-as-a-Service (ACaaS) (draft-ietf-opsawg-teas-attachment-circuit)


Dear authors,

With some delay (apologies for that), I have provided the shepherd's review of 
draft-ietf-opsawg-teas-attachment-circuit.

The review is available here: 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/shepherdwriteup/
[Med] Thanks. I guess the writeup can indicate that this spec was presented to 
TEAS and that it was WGLCed there as well. Thanks.


Apart from the review provided I have some comments / suggestions / 
clarification questions:


  *   The title quotes 'Attachment Circuits', while in the text is not quoted 
at all. Probably better to follow the same approach always.
[Med] It is quoted to make as-a-service refers to the AC, not circuit. Changed 
one occurrence in the main text for consistency.


  *   Scope section refers to ancillary nodes, but the document does not 
include any definition of what an ancillary node refers to
[Med] Ancillary is used in reference to a connectivity service. An example is 
https://datatracker.ietf.org/doc/html/rfc9543#name-ancillary-ces.


  *   Section 1.1: s/... while the underlying link is referred to as "bearers" 
/... while the underlying link is referred to as "bearer"
[Med] ACK.


  *   Regarding the terminology to Network Slice service, not clear if should 
be prefixed as IETF Network Slice service (or not). Necessary to be aligned 
with the criteria that could be defined in TEAS WG.
[Med] ACK, although the AC can be used for other slice types.


  *   The document includes references to the other attachment circuit 
documents. I guess all these references should be updated to the corresponding 
RFC during the publication process. It could be interesting to add a note for 
the RFC editors to note this fact.
[Med] I don't think a note is needed here because the set of I-Ds will progress 
as a cluster. The RFC Editor will take care of that. Thanks.


  *   Section 2. Definition of Bearer. It is stated that one or multiple 
technologies can be used to build a bearer. It is not clear what are the 
implications of this. Does it imply concatenation? The YANG model describe 
applies to bearer from multiple technologies concatenated? An example of this 
would be beneficial.
[Med] Added the example of LAG.


  *   Section 4.1, last paragraph about protection. It is mentioned that the 
customer may request protection schemes when endpoints are te

[OPSAWG]Sheperd write-up for for YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (draft-ietf-opsawg-teas-attachment-circuit)

[LUIS MIGUEL CONTRERAS MURILLO]

Dear authors,

With some delay (apologies for that), I have provided the shepherd's review of 
draft-ietf-opsawg-teas-attachment-circuit.

The review is available here: 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/shepherdwriteup/

Apart from the review provided I have some comments / suggestions / 
clarification questions:


  *   The title quotes 'Attachment Circuits', while in the text is not quoted 
at all. Probably better to follow the same approach always.
  *   Scope section refers to ancillary nodes, but the document does not 
include any definition of what an ancillary node refers to
  *   Section 1.1: s/... while the underlying link is referred to as "bearers" 
/... while the underlying link is referred to as "bearer"
  *   Regarding the terminology to Network Slice service, not clear if should 
be prefixed as IETF Network Slice service (or not). Necessary to be aligned 
with the criteria that could be defined in TEAS WG.
  *   The document includes references to the other attachment circuit 
documents. I guess all these references should be updated to the corresponding 
RFC during the publication process. It could be interesting to add a note for 
the RFC editors to note this fact.
  *   Section 2. Definition of Bearer. It is stated that one or multiple 
technologies can be used to build a bearer. It is not clear what are the 
implications of this. Does it imply concatenation? The YANG model describe 
applies to bearer from multiple technologies concatenated? An example of this 
would be beneficial.
  *   Section 4.1, last paragraph about protection. It is mentioned that the 
customer may request protection schemes when endpoints are terminated by the 
same PE, but the customer in principle does not have any view of the provider 
network. Is that right? If so, how the customer knows that endpoints are on the 
same PE?
  *   Section 4.2. s/ This includes the flow put in place for the provisioning 
of network services ... / This includes the workflow put in place for the 
provisioning of network services ...
  *   Sentence above Figure 3. s/Figure 3 shows the positioning of the AC 
service model is the overall ... /Figure 3 shows the positioning of the AC 
service model in the overall ...
  *   The ietf-bearer-svc model has associated a customer-name. Does it mean 
that the bearer is bound to only one customer? Why a bearer is associated to a 
customer? What about the case of a shared medium (e.g., wifi link)?
  *   I think it is already reflected in the security considerations, but the 
reference of bearer or AC to customer could create privacy risks.
  *   Bearer-parent-ref, AC-parent-ref. Probably the notion of parent should be 
defined in terminology section.
  *   'test-only' can be a source of attacks and privacy risks. Probably it 
should be discussed in the security considerations.
  *   The full tree is documented in [AC-svc-tree] which is a personal report. 
I think it would be necessary to guarantee persistency on this by moving this 
to an IETF repository (or even the wiki).
  *   Below Figure 5, It is mentioned that each AC is identified with a unique 
name within a domain. Are we considering here administrative domains? Unique 
within a service provider? Which kind of domains apply to this restriction?
  *   The following paragraph mentions that the AC service model uses groupings 
and types defined in the AC common model. It would be convenient to list what 
groupings and types are used, so that it is evident to the reader those. This 
also would help to identify future augmentations or modifications.
  *   Figure 6, valid-provider-identifiers.
  *   'peer-SAP'. Since the document covers both perspectives (customer one and 
service provider one) it could be confusing in some cases the notion of 
peer-SAP. So it could be clarifying in some cases to refer to it as peer-SAP 
from the customer perspective, and so on.

Apologies again for the delay, hope the comments are helpful.

Best regards

Luis
_
Luis M. Contreras

Transport & IP Networks
Systems and Network Global Direction
Telefónica I+D / CTIO unit / Telefónica

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

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 confidential and 

Re: [OPSAWG] WG LC: Attachment circuits work

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all,

I support the progress of these drafts as key pieces for facilitating service 
automation.

Best regards

Luis

De: OPSAWG  En nombre de Joe Clarke (jclarke)
Enviado el: viernes, 19 de abril de 2024 16:41
Para: opsawg@ietf.org
CC: Traffic Engineering Architecture and Signaling Discussion List 

Asunto: [OPSAWG] WG LC: Attachment circuits work

AVISO/WARNING: Este correo electrónico se originó desde fuera de la 
organización. No haga clic en enlaces ni abra archivos adjuntos a menos que 
reconozca al remitente y sepa que el contenido es seguro / This email has been 
originated from outside of the organization. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.

Thanks to efforts by the WG and cross-collaboration with TEAS, these four 
drafts are at the point to run a WG LC.  All currently reported issues have 
been resolved by the authors, and we are grateful to have four volunteers for 
shepherds.

The Attachment Circuits work is divided into four documents:

https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-common-ac/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntw-attachment-circuit/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ac-lxsm-lxnm-glue/

Given the size of the work, we will run for a three-week LC period (closing on 
May 10), and we are copying teas@ for additional reviews.  Please reply on-list 
with comments.

Joe



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 confidential and privileged 
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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[alto] RV: New Version Notification for draft-contreras-tvr-alto-exposure-03.txt

[LUIS MIGUEL CONTRERAS MURILLO]

Dear ALTOers,

This is just to inform about an ALTO-related effort I'm moving forward in TVR. 
In case of your interest on that, my intention is to request adoption in next 
IETF 119. Whatever comment you could consider relevant is always welcome, 
hopefully better on TVR mailing list.

Best regards

Luis

-Mensaje original-
De: LUIS MIGUEL CONTRERAS MURILLO
Enviado el: sábado, 2 de marzo de 2024 11:32
Para: t...@ietf.org
Asunto: RV: New Version Notification for 
draft-contreras-tvr-alto-exposure-03.txt

Dear all,

This week I submitted a new version of draft-contreras-tvr-alto-exposure. I 
would like to ask for comments / reviews of the draft. At this stage I think 
the draft have addressed all the comments received so far. My purpose for IETF 
119 would be to ask the chairs for triggering the adoption poll (if they 
consider the draft ready, of course), so it would be very much appreciated 
whatever any comment that could come from the WG participants.

Thanks in advance

Best regards

Luis


-Mensaje original-
De: internet-dra...@ietf.org  Enviado el: martes, 27 
de febrero de 2024 20:00
Para: LUIS MIGUEL CONTRERAS MURILLO 
; LUIS MIGUEL CONTRERAS MURILLO 

Asunto: New Version Notification for draft-contreras-tvr-alto-exposure-03.txt

A new version of Internet-Draft draft-contreras-tvr-alto-exposure-03.txt has 
been successfully submitted by Luis M. Contreras and posted to the IETF 
repository.

Name: draft-contreras-tvr-alto-exposure
Revision: 03
Title:Using ALTO for exposing Time-Variant Routing information
Date: 2024-02-27
Group:Individual Submission
Pages:9
URL:  
https://www.ietf.org/archive/id/draft-contreras-tvr-alto-exposure-03.txt
Status:   https://datatracker.ietf.org/doc/draft-contreras-tvr-alto-exposure/
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-contreras-tvr-alto-exposure
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-contreras-tvr-alto-exposure-03

Abstract:

   Network operations can require time-based, scheduled changes in
   nodes, links, adjacencies, etc.  All those changes can alter the
   connectivity in the network in a predictable manner, which is known
   as Time-Variant Routing (TVR).  Existing IETF solutions like ALTO can
   assist, as an off-path mechanism, on the exposure of such predicted
   changes to both internal and external applications then anticipating
   the occurrence of routing changes.  This document describes how ALTO
   helps in that purpose.



The IETF Secretariat





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 confidential and privileged 
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

Re: [Pce] RV: New Version Notification for draft-contreras-pce-pam-02.txt

[LUIS MIGUEL CONTRERAS MURILLO]

Thanks Dhruv!

Noted, we will continue with the analysis, my expectation is to report the 
progress at IETF 119 so I can provide more info about the analysis

Thanks again,

Luis

De: Dhruv Dhody 
Enviado el: martes, 27 de febrero de 2024 6:17
Para: LUIS MIGUEL CONTRERAS MURILLO 
CC: Dhruv Dhody ; pce@ietf.org
Asunto: Re: [Pce] RV: New Version Notification for 
draft-contreras-pce-pam-02.txt

Hi Luis,

On Mon, Feb 26, 2024 at 11:59 PM LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
 wrote:
Hi Dhruv,

Sorry for my late response.

In version -01 we proposed a new METRIC Object-type within the existing 
object-class, but after internal analysis we decided to propose a new object in 
this version -02. We think is much cleaner approach and allows to re-use 
attributes already defined. Probably easier as well to parse and facilitate 
backward compatibility with existing implementations.


I am not sure I agree that the approach is much cleaner, but those can be 
subjective. Just looking at the number of PCEP objects that have different 
object-types at https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects , 
it feels this is the established practice for PCEP extensions and 
implementations already does the encoding/decoding for lot of PCEP objects.

Regarding the potential impacts in terms of RBNF grammar. Do you have any 
pointer or clue for better understanding such kind of impacts on the Routing 
Backus-Naur Form?


The impact is just that you need to update the RBNF for every PCEP message that 
can carry this new object whereas in case of using an existing object you
just get it for free :)

An example can be seen at recent objects added CCI, BU in RFC9050 and RFC8233 
respectively.

Thanks!
Dhruv


Thanks in advance,

Best regards

Luis

De: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Enviado el: miércoles, 14 de febrero de 2024 5:42
Para: LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
CC: pce@ietf.org<mailto:pce@ietf.org>
Asunto: Re: [Pce] RV: New Version Notification for 
draft-contreras-pce-pam-02.txt

H Luis, WG,

Did you consider defining a new METRIC Object-type (within the existing 
object-class 6) called Precision instead of defining a brand new object with 
new object-class/object-type?

If we choose to define just a new object-type, it has an added advantage of 
keeping the RBNF grammar cleaner and we dont need to extend it.

Thoughts?

Thanks!
Dhruv

On Wed, Feb 14, 2024 at 12:57 AM LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
 wrote:
Dear all,

We have just updated draft-contreras-pce-pam in the following way:

- we have changed the approach moving from extending existing METRIC object to 
proposing a new PRECISION METRIC object. The reason for that is we consider it 
as a cleaner approach, also allowing clearer structure.

- we have also addressed the question raised by Dhruv (as chair) at IETF 118 
about the convenience of including some example.

- editorial clean-up.

With this we think all the comments in IETF 118 have been addressed.

Any further comment / suggestion is more than welcome.

Best regards

Luis



-Mensaje original-
De: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Enviado el: martes, 13 de febrero de 2024 20:22
Para: LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>;
 Fernando Agraz mailto:fernando.ag...@upc.edu>>; LUIS 
MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>;
 salvatore.spadaro mailto:salvatore.spad...@upc.edu>>
Asunto: New Version Notification for draft-contreras-pce-pam-02.txt

A new version of Internet-Draft draft-contreras-pce-pam-02.txt has been 
successfully submitted by Luis M. Contreras and posted to the IETF repository.

Name: draft-contreras-pce-pam
Revision: 02
Title:Path Computation Based on Precision Availability Metrics
Date: 2024-02-13
Group:Individual Submission
Pages:14
URL:  https://www.ietf.org/archive/id/draft-contreras-pce-pam-02.txt
Status:   https://datatracker.ietf.org/doc/draft-contreras-pce-pam/
HTMLized: https://datatracker.ietf.org/doc/html/draft-contreras-pce-pam
Diff: https://author-tools.ietf.org/iddiff?url2=draft-contreras-pce-pam-02

Abstract:

   The Path Computation Element (PCE) is able of determining paths
   according to constraints expressed in the form of metrics.  The value
   of the metric can be signaled as a bound or maximum, meaning that
   path metric must be less than or equal such value.  While this can be
   sufficient for certain services, some others can require the
   utilization of Precision Availability Metrics (PAM).  This document
   defines a new object, namely the PRECISION METRIC object, to be used
   for path calculation or selection for networking services with
   performance req

Re: [Pce] RV: New Version Notification for draft-contreras-pce-pam-02.txt

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Dhruv,

Sorry for my late response.

In version -01 we proposed a new METRIC Object-type within the existing 
object-class, but after internal analysis we decided to propose a new object in 
this version -02. We think is much cleaner approach and allows to re-use 
attributes already defined. Probably easier as well to parse and facilitate 
backward compatibility with existing implementations.

Regarding the potential impacts in terms of RBNF grammar. Do you have any 
pointer or clue for better understanding such kind of impacts on the Routing 
Backus-Naur Form?

Thanks in advance,

Best regards

Luis

De: Dhruv Dhody 
Enviado el: miércoles, 14 de febrero de 2024 5:42
Para: LUIS MIGUEL CONTRERAS MURILLO 
CC: pce@ietf.org
Asunto: Re: [Pce] RV: New Version Notification for 
draft-contreras-pce-pam-02.txt

H Luis, WG,

Did you consider defining a new METRIC Object-type (within the existing 
object-class 6) called Precision instead of defining a brand new object with 
new object-class/object-type?

If we choose to define just a new object-type, it has an added advantage of 
keeping the RBNF grammar cleaner and we dont need to extend it.

Thoughts?

Thanks!
Dhruv

On Wed, Feb 14, 2024 at 12:57 AM LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
 wrote:
Dear all,

We have just updated draft-contreras-pce-pam in the following way:

- we have changed the approach moving from extending existing METRIC object to 
proposing a new PRECISION METRIC object. The reason for that is we consider it 
as a cleaner approach, also allowing clearer structure.

- we have also addressed the question raised by Dhruv (as chair) at IETF 118 
about the convenience of including some example.

- editorial clean-up.

With this we think all the comments in IETF 118 have been addressed.

Any further comment / suggestion is more than welcome.

Best regards

Luis



-Mensaje original-
De: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Enviado el: martes, 13 de febrero de 2024 20:22
Para: LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>;
 Fernando Agraz mailto:fernando.ag...@upc.edu>>; LUIS 
MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>;
 salvatore.spadaro mailto:salvatore.spad...@upc.edu>>
Asunto: New Version Notification for draft-contreras-pce-pam-02.txt

A new version of Internet-Draft draft-contreras-pce-pam-02.txt has been 
successfully submitted by Luis M. Contreras and posted to the IETF repository.

Name: draft-contreras-pce-pam
Revision: 02
Title:Path Computation Based on Precision Availability Metrics
Date: 2024-02-13
Group:Individual Submission
Pages:14
URL:  https://www.ietf.org/archive/id/draft-contreras-pce-pam-02.txt
Status:   https://datatracker.ietf.org/doc/draft-contreras-pce-pam/
HTMLized: https://datatracker.ietf.org/doc/html/draft-contreras-pce-pam
Diff: https://author-tools.ietf.org/iddiff?url2=draft-contreras-pce-pam-02

Abstract:

   The Path Computation Element (PCE) is able of determining paths
   according to constraints expressed in the form of metrics.  The value
   of the metric can be signaled as a bound or maximum, meaning that
   path metric must be less than or equal such value.  While this can be
   sufficient for certain services, some others can require the
   utilization of Precision Availability Metrics (PAM).  This document
   defines a new object, namely the PRECISION METRIC object, to be used
   for path calculation or selection for networking services with
   performance requirements expressed as Service Level Objectives (SLO)
   using PAM.



The IETF Secretariat





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 confidential and privileged 
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 pess

[Pce] RV: New Version Notification for draft-contreras-pce-pam-02.txt

[LUIS MIGUEL CONTRERAS MURILLO]

Dear all,

We have just updated draft-contreras-pce-pam in the following way:

- we have changed the approach moving from extending existing METRIC object to 
proposing a new PRECISION METRIC object. The reason for that is we consider it 
as a cleaner approach, also allowing clearer structure.

- we have also addressed the question raised by Dhruv (as chair) at IETF 118 
about the convenience of including some example.

- editorial clean-up.

With this we think all the comments in IETF 118 have been addressed.

Any further comment / suggestion is more than welcome.

Best regards

Luis



-Mensaje original-
De: internet-dra...@ietf.org 
Enviado el: martes, 13 de febrero de 2024 20:22
Para: LUIS MIGUEL CONTRERAS MURILLO 
; Fernando Agraz 
; LUIS MIGUEL CONTRERAS MURILLO 
; salvatore.spadaro 

Asunto: New Version Notification for draft-contreras-pce-pam-02.txt

A new version of Internet-Draft draft-contreras-pce-pam-02.txt has been 
successfully submitted by Luis M. Contreras and posted to the IETF repository.

Name: draft-contreras-pce-pam
Revision: 02
Title:Path Computation Based on Precision Availability Metrics
Date: 2024-02-13
Group:Individual Submission
Pages:14
URL:  https://www.ietf.org/archive/id/draft-contreras-pce-pam-02.txt
Status:   https://datatracker.ietf.org/doc/draft-contreras-pce-pam/
HTMLized: https://datatracker.ietf.org/doc/html/draft-contreras-pce-pam
Diff: https://author-tools.ietf.org/iddiff?url2=draft-contreras-pce-pam-02

Abstract:

   The Path Computation Element (PCE) is able of determining paths
   according to constraints expressed in the form of metrics.  The value
   of the metric can be signaled as a bound or maximum, meaning that
   path metric must be less than or equal such value.  While this can be
   sufficient for certain services, some others can require the
   utilization of Precision Availability Metrics (PAM).  This document
   defines a new object, namely the PRECISION METRIC object, to be used
   for path calculation or selection for networking services with
   performance requirements expressed as Service Level Objectives (SLO)
   using PAM.



The IETF Secretariat





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 confidential and privileged 
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
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [OPSAWG]  WG Adoption Call for draft-feng-opsawg-incident-management-04

[LUIS MIGUEL CONTRERAS MURILLO]

Dear Henk, all,

As co-author, I support the adoption of the draft.

Thanks, best regards

Luis

-Mensaje original-
De: OPSAWG  En nombre de Henk Birkholz
Enviado el: jueves, 8 de febrero de 2024 16:44
Para: OPSAWG 
Asunto: [OPSAWG]  WG Adoption Call for draft-feng-opsawg-incident-management-04

Dear OPSAWG members,

this email starts a call for Working Group Adoption of

> https://www.ietf.org/archive/id/draft-feng-opsawg-incident-management-
> 04.html

ending on Thursday, February 22nd.

As a reminder, this I-D specifies a YANG Module for Incident Management.
Incidents in this context are scoped to unexpected yet quantifiable adverse 
effects detected in a network service. The majority of the document provides 
background and motivation for the structure of the YANG Module that is in 
support of reporting, diagnosing, and mitigating the detected adverse effects.

The chairs acknowledge some positive feedback on the list and a positive poll 
result at IETF118. We would like to gather feedback from the WG if there is 
interest to further contribute and review.

Please reply with your support and especially any substantive comments you may 
have.


For the OPSAWG co-chairs,

Henk

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg



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 confidential and privileged 
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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  IPR Call for draft-feng-opsawg-incident-management-04

[LUIS MIGUEL CONTRERAS MURILLO]

Dear chairs,

No, I am not aware of any IPR related to this work.

Thanks

Best regards

Luis

-Mensaje original-
De: Henk Birkholz 
Enviado el: jueves, 8 de febrero de 2024 17:00
Para: OPSAWG ; draft-feng-opsawg-incident-managem...@ietf.org
Asunto:  IPR Call for draft-feng-opsawg-incident-management-04

Dear authors and contributors,

as a part of the adoption process, the chairs would also like to issue a first 
IPR call on the content of adoption candidates (there will also be a second IPR 
call after successful WGLC).

Please respond on-list as to whether or not you are aware of any IPR that 
pertains to draft-feng-opsawg-incident-management-04.

If you are aware of IPR, please also indicate whether or not this has been 
disclosed per IETF IPR rules (see RFCs 3669, 5378, and 8179).


For the OPAWG co-chairs,

Henk



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 confidential and privileged 
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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [alto] PCE

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Martin

Thanks for commenting.

PCE and ALTO work on different aspects. PCE allows to calculate and/or select 
the best path among network border elements according to some constraints 
(e.g., latency). Besides that, the PCE can trigger the establishment of such 
path leveraging on tunneling capabilities, e.g. using Segment Routing with 
Traffic Engineering.

On the other hand, as you know well, with ALTO it is possible to expose network 
and cost maps for PIDs attached to network border elements.

So, while PCE intention is to build constrained paths, ALTO aim is to expose 
them. Certainly, ALTO could leverage on PCE information for creating the 
network and cost maps (case not yet elaborated in the form of an RFC or draft, 
that is, definition of an SBI for retrieving PCE information extracting info 
from PCE-related databases), but also other forms of interworking could be 
considered (e.g., ALTO triggering PCE computation of paths). These potential 
interworking actions could be a matter of a charter item for SBI developments 
in ALTO WG (or a sequel of it).

Best regards

Luis

De: alto  En nombre de Martin Duke
Enviado el: lunes, 27 de noviembre de 2023 20:00
Para: IETF ALTO 
Asunto: [alto] PCE

Hi ALTO,

In my email announcing the impending closure of ALTO, I mentioned a number of 
potential outlets for future work. I neglected to mention 
PCE, which to me seems to covering 
a similar problem area. If they haven't already, I would encourage ALTO 
practitioners to investigate PCE's activities and see where ALTO solves their 
problems, or PCE work solves current ALTO problems.

Similarly, people working on PCE probably have issues with assembling a 
topology database, and would probably be fruitful partners for those working on 
assembling the ALTO database.

Thanks,
Martin



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 confidential and privileged 
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


Le informamos de que el responsable del tratamiento de sus datos es la entidad 
del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el 
contacto profesional y gestionar la relación establecida con el destinatario o 
con la entidad a la que está vinculado. Puede contactar con el responsable del 
tratamiento y ejercitar sus derechos escribiendo a 
privacidad@telefonica.com. Puede 
consultar información adicional sobre el tratamiento de sus datos en nuestra 
Política de 
Privacidad.

We inform you that the data controller is the Telefónica Group entity linked to 
the sender, for the purpose of maintaining professional contact and managing 
the relationship established with the recipient or with the entity to which it 
is linked. You may contact the data controller and exercise your rights by 
writing to privacidad@telefonica.com. 
You may consult additional information on the processing of your data in our 
Privacy 
Policy.

Informamos que o responsável pelo tratamento dos seus dados é a entidade do 
Grupo Telefónica vinculada ao remetente, a fim de manter o contato professional 
e administrar a relação estabelecida com o destinatário ou com a entidade à 
qual esteja vinculado. Você pode entrar em contato com o 

Re: [OPSAWG] Time Schedule Side Meeting Update

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Qin, all,

Thanks for the summary.

As also commented, this is as well an opportunity to check if the parameters 
considered in the model are sufficient. For instance, I miss some time zone 
parameter which can be relevant for networks spanning more than one time zone 
(e.g., international carriers' networks) where the scheduling could require 
some time zone awareness. Let's discuss these things during the draft alignment 
process.

Thanks again

Best regards

Luis

De: OPSAWG  En nombre de Qin Wu
Enviado el: viernes, 10 de noviembre de 2023 10:02
Para: opsawg@ietf.org
CC: Yingzhen Qu 
Asunto: [OPSAWG] Time Schedule Side Meeting Update


Hi,

Thanks to all folks who participated in the time schedule discussion on 
Thursday afternoon and provided good inputs; the side meeting spent one-hour 
discussing common model design for various use cases described in:



https://datatracker.ietf.org/doc/draft-ma-opsawg-schedule-yang/ (ACL policy 
activation based on date and time conditions)



https://datatracker.ietf.org/doc/draft-united-tvr-schedule-yang/ (manage 
network resources with time scheduled changes)



https://datatracker.ietf.org/doc/draft-contreras-opsawg-scheduling-oam-tests/ 
(schedule on-demand OAM tests)



We focused on the uses cases and network resource management with 
time-scheduled changes for the TVR scenarios. We do not see any issue with the 
scheduled OAM use cases and can create examples for human-readable and 
machine-readable scenarios.



The authors of draft-united-tvr-schedule-yang and 
draft-contreras-opsawg-scheduling-oam-tests agreed to use common building 
blocks such as grouping defined in draft-ma-opsawg-schedule-yang, once we show 
some examples that meet their requirements. The usage examples for other use 
cases will be provided in draft-ma-opsawg-schedule-yang in an appendix. The 
authors of draft-united-tvr-schedule-yang and 
draft-contreras-opsawg-scheduling-oam-tests will review and align with changes 
made in draft-ma-opsawg-schedule-yang to address their needs.



Thanks again to everyone involved in the discussion; it was a very productive 
meeting and will ensure the reusability of models across different working 
groups."

-Qin (on behalf of the team)



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 confidential and privileged 
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


Le informamos de que el responsable del tratamiento de sus datos es la entidad 
del Grupo Telef?nica vinculada al remitente, con la finalidad de mantener el 
contacto profesional y gestionar la relaci?n establecida con el destinatario o 
con la entidad a la que est? vinculado. Puede contactar con el responsable del 
tratamiento y ejercitar sus derechos escribiendo a 
privacidad@telefonica.com. Puede 
consultar informaci?n adicional sobre el tratamiento de sus datos en nuestra 
Pol?tica de 
Privacidad.

We inform you that the data controller is the Telef?nica Group entity linked to 
the sender, for the purpose of maintaining professional contact and managing 
the relationship established with the recipient or with the entity to which it 
is linked. You may contact the data controller and exercise your rights by 
writing to privacidad@telefonica.com. 
You may consult additional information on the processing of your data in our 
Privacy 

Re: [alto] New draft on joint exposure of network and compute information

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Adrian, all,

I think that the approach is for what purpose we need the compute metrics, 
rather than who will make use of them (i.e. CATS, ALTO, etc).

In our view we need compute-related metrics for the entire service lifecycle: 
instantiation, traffic steering, assurance, migration, etc. So our proposal is 
to define consistent metrics that could serve for all those purposes, 
independently of who use them (which could happen at different stages of the 
service lifecycle by different solutions).

In a simple analogy with networking metrics, latency or packet loss apply to 
whatever stage of the service lifecycle we are considering (e.g., path 
computation, traffic forwarding, monitoring of communication service health, 
etc).

Best regards

Luis

De: alto  En nombre de Adrian Farrel
Enviado el: jueves, 2 de noviembre de 2023 21:43
Para: 'Jordi Ros Giralt' ; 'Linda Dunbar' 
; c...@ietf.org; alto@ietf.org
Asunto: Re: [alto] New draft on joint exposure of network and compute 
information

So, my view is that CATS is specifically chartered to look at these metrics. I 
think the metrics could equally be applied in ALTO (as I said at IETF-117 in 
the ALTO WG meeting).
I had hoped that we might hold an interim to discuss metrics, but progress has 
been slow.
That said, the CATS list has recently been discussing metrics a bit, and I hope 
we can build on that.
I would like to hear lots of opinions. At the moment, I don't mind much whether 
there is consensus or strong debate. I'd just like to hear many voices.
What are the factors:

  *   Simple?
  *   Generic?
  *   Variable or static?
  *   Actual compute load/capability versus anticipated delay for a "standard" 
compute action?
  *   

Cheers,
Adrian

From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
Jordi Ros Giralt
Sent: 02 November 2023 17:58
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; 
c...@ietf.org; alto@ietf.org
Subject: Re: [alto] New draft on joint exposure of network and compute 
information

Thanks Linda.

These metrics can be common to a variety of use cases. That is, the same common 
metrics can be used to support the CATS use cases (exposure to the ingress 
point) or (as suggested by this draft) to support service providers and 
applications to make service deployment and selection decisions. The two 
efforts (network and application layer) can complement each other to achieve 
the performance requirements.

As for metrics, it depends on the application, but certainly on the compute 
side, CPU, GPU, NPU, memory, storage are all important to make proper placement 
and selection decisions. A good part is that, in general, for a given 
application (e.g., AI inference), the requirements to run it are generally 
well-known at deployment/selection time.

Thanks,
Jordi

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Sent: Wednesday, November 1, 2023 18:15
To: Jordi Ros Giralt mailto:j...@qti.qualcomm.com>>; 
c...@ietf.org mailto:c...@ietf.org>>; 
alto@ietf.org mailto:alto@ietf.org>>
Subject: RE: New draft on joint exposure of network and compute information


WARNING: This email originated from outside of Qualcomm. Please be wary of any 
links or attachments, and do not enable macros.

Jordi,



In addition, CATS WG is discussing many more metrics that can impact the 
service performance.



Really appreciate if you can elaborate more on the new metrics that impact the 
deployment and path section. It will be very useful.



Thanks, Linda







From: Linda Dunbar
Sent: Wednesday, November 1, 2023 12:11 PM
To: Jordi Ros Giralt mailto:j...@qti.qualcomm.com>>; 
c...@ietf.org; alto@ietf.org
Cc: i...@ietf.org
Subject: RE: New draft on joint exposure of network and compute information



Jordi,



Your draft describes two aspects of the service performance impacted by the 
Computing: Service Deployment and  Service (Path) Selection. Those two should 
be separated, as the Service Deployment belongs to the OpsArea, and the Service 
selection (including Network Path & DCs that host the services) belongs to the 
Routing area.



https://datatracker.ietf.org/doc/draft-ietf-idr-5g-edge-service-metadata/ has 
proposed a new Metadata Path Attribute and some Sub-TLVs  for egress routers to 
advertise the Metadata about the attached edge  services (ES).  The Edge 
Service Metadata can be used by the ingress routers in the 5G Local Data 
Network to make path selections not only based on the routing cost but also the 
running environment of the edge services.  The goal is to improve latency and 
performance for 5G  edge services.





Can this Metadata Path Attribute address the problem stated in your draft?  I 
CC'ed the IDR WG, so your comments on the Path Selection can be visible to them.



Thanks, Linda





From: Cats mailto:cats-boun...@ietf.org>> On 

Re: [alto] [Cats] [Idr] New draft on joint exposure of network and compute information

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Joel, all,

Please, see in-line

Best regards

Luis

De: Cats  En nombre de Joel Halpern
Enviado el: jueves, 2 de noviembre de 2023 19:04
Para: Jordi Ros Giralt ; Linda Dunbar 
; c...@ietf.org; alto@ietf.org
CC: i...@ietf.org
Asunto: Re: [Cats] [Idr] New draft on joint exposure of network and compute 
information


There are, as far as I can tell, two very valid and very different approaches 
to service selection / traffic direction.

[[Luis>]] service selection / traffic direction is a part of the problem. A 
previous step is service / application instantiation. What we claim is the 
convenience of defining compute-related metrics suitable for both (and any 
other step in the service lifecycle that could require such kind of metrics). 
Defining separated metrics could lead to inconsistent approaches. A common set 
of metrics that could be used for different purposes would be desirable.



It can be done by the application, or it can be done by the operator edge.  
CATS is chartered to address the operator-based approach.  Applications clearly 
can chose to make their own decision, or to send anycast traffic allowing CATS 
to make its decision.



However, expecting the network to expose detailed topology and related metrics 
to end application clients seems unlikely.

[[Luis>]] Exposing information from network side is becoming an industrial 
trend in order to benefit the service delivery and experience by customers 
(e.g. Linux CAMARA project). Closer interaction among applications and networks 
is desirable.



Which is why most applications have taken the approach of using their own 
probes to make their decisions.

[[Luis>]] The applications following that approach infer the status of the 
network for taking decisions. Though proper exposure mechanisms the 
applications could take informed decisions in a more precise manner than the 
inference, which will be certainly beneficial. However this discussion 
separates from the topic of the draft (common definition of compute metrics), 
so maybe better discuss in a thread apart.



  If you want to argue for a protocol to expose information to client 
applications, that is a very complicated discussion with many stakeholders.  
And it is a discussion that needs to take place before one discusses exact 
metrics, or even the properties of such an exposure mechanism.  (It is an 
approach much closer to ALTO than to CATS.)



Yours,

Joel


On 11/2/2023 1:45 PM, Jordi Ros Giralt wrote:
Thanks Linda for your comments. Find my responses below:


> Your draft describes two aspects of the service performance

> impacted by the Computing: Service Deployment and  Service (Path)

> Selection. Those two should be separated, as the Service Deployment

> belongs to the OpsArea, and the Service selection (including Network

> Path & DCs that host the services) belongs to the Routing area.

[JRG] I agree that service deployment can be seen as part of ops area. Service 
selection can both be seen as part of the routing area (as you point out), but 
also a part of the application area. For instance, an application running in a 
UE could decide whether to use 5G, 4G, or Wi-Fi to connect to a service 
instance based on the communication and compute resource information exposed to 
it.


> draft-ietf-idr-5g-edge-service-metadata has proposed a new Metadata Path

> Attribute and some Sub-TLVs  for egress routers to advertise the Metadata

> about the attached edge services (ES).

> (...) Can this Metadata Path Attribute address the problem stated in your 
> draft?



[JRG] I agree this information is valuable to the ingress router to make path 
selection decisions. In addition, there is also a need for this information to 
be exposed to the service or application layer. If there is service 
replication, the application running in the UE (or an application-layer proxy 
on behalf of it) needs to decide which of the service replicas it connects to. 
Once a service replica is selected, the UE might also have a variety of ways to 
reach that service (e.g., 4G, 5G, Wi-Fi). Both of these end-point selection 
decisions need to know the available communication and compute resources.



Thanks,

Jordi







From: Linda Dunbar 

Sent: Wednesday, November 1, 2023 18:11
To: Jordi Ros Giralt ; 
c...@ietf.org ; 
alto@ietf.org 
Cc: i...@ietf.org 
Subject: RE: New draft on joint exposure of network and compute information


WARNING: This email originated from outside of Qualcomm. Please be wary of any 
links or attachments, and do not enable macros.

Jordi,



Your draft describes two aspects of the service performance impacted by the 
Computing: Service Deployment and  Service (Path) Selection. Those two should 
be separated, as the Service Deployment belongs to 

[OPSAWG] Session slot request in OPSAWG for draft-contreras-opsawg-scheduling-oam-tests

[LUIS MIGUEL CONTRERAS MURILLO]

Dear chairs,

We would like to request a slot for presenting 
draft-contreras-opsawg-scheduling-oam-tests.

In both IETF 116 and IETF 117 we appeared in agenda but lack of time not 
permitted us to present the draft. We would like to have the opportunity of 
doing so now in IETF 118. For that purpose 10 or 5 min would be sufficient.

Thanks

Luis & Victor

_
Luis M. Contreras

Transport & IP Networks
Systems and Network Global Direction
Telefónica I+D / CTIO unit / Telefónica

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

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 confidential and privileged 
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


Le informamos de que el responsable del tratamiento de sus datos es la entidad 
del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el 
contacto profesional y gestionar la relación establecida con el destinatario o 
con la entidad a la que está vinculado. Puede contactar con el responsable del 
tratamiento y ejercitar sus derechos escribiendo a 
privacidad@telefonica.com. Puede 
consultar información adicional sobre el tratamiento de sus datos en nuestra 
Política de 
Privacidad.

We inform you that the data controller is the Telefónica Group entity linked to 
the sender, for the purpose of maintaining professional contact and managing 
the relationship established with the recipient or with the entity to which it 
is linked. You may contact the data controller and exercise your rights by 
writing to privacidad@telefonica.com. 
You may consult additional information on the processing of your data in our 
Privacy 
Policy.

Informamos que o responsável pelo tratamento dos seus dados é a entidade do 
Grupo Telefónica vinculada ao remetente, a fim de manter o contato professional 
e administrar a relação estabelecida com o destinatário ou com a entidade à 
qual esteja vinculado. Você pode entrar em contato com o responsável do 
tratamento de dados e exercer os seus direitos escrevendo a 
privacidad@telefonica.com. Você pode 
consultar informação adicional sobre o tratamento do seus dados na nossa 
Política de 
Privacidade.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [DMM] DMM WG Adoption Poll (2) for "Mobile User Plane Evolution" - draft-zzhang-dmm-mup-evolution-06

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all,

As co-author, I support the adoption of this document.

Best regards

Luis

De: Satoru Matsushima 
Enviado el: jueves, 19 de octubre de 2023 11:41
Para: dmm 
CC: draft-zzhang-dmm-mup-evolut...@ietf.org
Asunto: DMM WG Adoption Poll (2) for "Mobile User Plane Evolution" - 
draft-zzhang-dmm-mup-evolution-06

Dear DMMers,

This email starts a two-weeks DMM WG adoption poll (2) for ""Mobile User Plane 
Evolution" - draft-zzhang-dmm-mup-evolution-06.

https://datatracker.ietf.org/doc/draft-zzhang-dmm-mup-evolution/

Please review the draft and post any comments on this mail thread prior to 
Friday, November 3rd, 2023.

Regards,
Sri, Satoru




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 confidential and privileged 
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


Le informamos de que el responsable del tratamiento de sus datos es la entidad 
del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el 
contacto profesional y gestionar la relación establecida con el destinatario o 
con la entidad a la que está vinculado. Puede contactar con el responsable del 
tratamiento y ejercitar sus derechos escribiendo a 
privacidad@telefonica.com. Puede 
consultar información adicional sobre el tratamiento de sus datos en nuestra 
Política de 
Privacidad.

We inform you that the data controller is the Telefónica Group entity linked to 
the sender, for the purpose of maintaining professional contact and managing 
the relationship established with the recipient or with the entity to which it 
is linked. You may contact the data controller and exercise your rights by 
writing to privacidad@telefonica.com. 
You may consult additional information on the processing of your data in our 
Privacy 
Policy.

Informamos que o responsável pelo tratamento dos seus dados é a entidade do 
Grupo Telefónica vinculada ao remetente, a fim de manter o contato professional 
e administrar a relação estabelecida com o destinatário ou com a entidade à 
qual esteja vinculado. Você pode entrar em contato com o responsável do 
tratamento de dados e exercer os seus direitos escrevendo a 
privacidad@telefonica.com. Você pode 
consultar informação adicional sobre o tratamento do seus dados na nossa 
Política de 
Privacidade.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[alto] RV: New Version Notification for draft-contreras-tvr-alto-exposure-02.txt

[LUIS MIGUEL CONTRERAS MURILLO]

Dear all, fyi,

A new version of draft-contreras-tvr-alto-exposure has been produced for the 
TVR WG. As a reminder, the document proposes an off-path solution for exposing 
planned changes on nodes and links according to the time-variant routing scope. 
For doing so, the document leverages on the Cost Calendar functionality 
specified in RFC8896.

This version includes an initial assessment against TVR requirements. In some 
particular case, i.e. the requirement of time overlap and priority 
([I-D.ietf-tvr-requirements], section 3.2.7), the compliance with such 
requirement requires extension of ALTO Cost Calendar, according to the analysis.

The expectation is to present this new version at IETF 118 in TVR WG. Comments 
and suggestions are more than welcome.

Best regards

Luis

-Mensaje original-
De: internet-dra...@ietf.org 
Enviado el: sábado, 14 de octubre de 2023 14:34
Para: LUIS MIGUEL CONTRERAS MURILLO 
; LUIS MIGUEL CONTRERAS MURILLO 

Asunto: New Version Notification for draft-contreras-tvr-alto-exposure-02.txt

A new version of Internet-Draft draft-contreras-tvr-alto-exposure-02.txt has 
been successfully submitted by Luis M. Contreras and posted to the IETF 
repository.

Name: draft-contreras-tvr-alto-exposure
Revision: 02
Title:Using ALTO for exposing Time-Variant Routing information
Date: 2023-10-14
Group:Individual Submission
Pages:9
URL:  
https://www.ietf.org/archive/id/draft-contreras-tvr-alto-exposure-02.txt
Status:   https://datatracker.ietf.org/doc/draft-contreras-tvr-alto-exposure/
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-contreras-tvr-alto-exposure
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-contreras-tvr-alto-exposure-02

Abstract:

   Network operations can require time-based, scheduled changes in
   nodes, links, adjacencies, etc.  All those changes can alter the
   connectivity in the network in a predictable manner, which is known
   as Time-Variant Routing (TVR).  Existing IETF solutions like ALTO can
   assist, as an off-path mmechanism, on the exposure of such predicted
   changes to both internal and external applications then anticipating
   the occurence of routing changes.  This document describes how ALTO
   helps in that purpose.



The IETF Secretariat





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 confidential and privileged 
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


Le informamos de que el responsable del tratamiento de sus datos es la entidad 
del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el 
contacto profesional y gestionar la relación establecida con el destinatario o 
con la entidad a la que está vinculado. Puede contactar con el responsable del 
tratamiento y ejercitar sus derechos escribiendo a 
privacidad@telefonica.com<mailto:privacidad@telefonica.com>. Puede 
consultar información adicional sobre el tratamiento de sus datos en nuestra 
Política de 
Privacidad<https://www.telefonica.com/es/telefonica-politica-de-privacidad-de-terceros/>.

We inform you that the data controller is the Telefónica Group entity linked to 
the sender, for the purpose of maintaining professional contact and managing 
the relationship established with the recipient or with the entity to which it 
is linked. You may contact the data controller and exercise your rights by 
writing to privacidad@telefonica.com<mailto:privacidad@telefonica.com>. 
You may consult additional information on the proce

Re: [OPSAWG] CALL FOR ADOPTION: Attachment circuits work

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all,

I do support the work on this set of drafts. They define necessary artifacts 
for the goal of automation. A clear case in the context of IETF is the one of 
network slicing.

Best regards

Luis

Enviado desde Outlook para Android


De: OPSAWG  en nombre de Joe Clarke (jclarke) 

Enviado: lunes, octubre 2, 2023 3:22:13 p. m.
Para: opsawg@ietf.org 
Asunto: [OPSAWG] CALL FOR ADOPTION: Attachment circuits work

At IETF 117, we asked the room if there was support to adopt the four 
attachment circuits drafts.  The room had support (of the 75 present, 18 raised 
hands for adoption interest, 1 was opposed), but the list is where it counts.

While the drafts aren’t too terribly long, there are four of them, so we will 
do a three week call for adoption.  Please review and comment on-list on the 
following indicating whether you support their adoption or not:


  *   draft-boro-opsawg-teas-common-ac
  *   draft-boro-opsawg-teas-attachment-circuit
  *   draft-boro-opsawg-ntw-attachment-circuit
  *   draft-boro-opsawg-ac-lxsm-lxnm-glue

The authors and contributors have all signaled there is no known IPR covering 
this work.

The CfA will end on October 23.

Thanks.

Joe




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 confidential and privileged 
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


Le informamos de que el responsable del tratamiento de sus datos es la entidad 
del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el 
contacto profesional y gestionar la relación establecida con el destinatario o 
con la entidad a la que está vinculado. Puede contactar con el responsable del 
tratamiento y ejercitar sus derechos escribiendo a 
privacidad@telefonica.com. Puede 
consultar información adicional sobre el tratamiento de sus datos en nuestra 
Política de 
Privacidad.

We inform you that the data controller is the Telefónica Group entity linked to 
the sender, for the purpose of maintaining professional contact and managing 
the relationship established with the recipient or with the entity to which it 
is linked. You may contact the data controller and exercise your rights by 
writing to privacidad@telefonica.com. 
You may consult additional information on the processing of your data in our 
Privacy 
Policy.

Informamos que o responsável pelo tratamento dos seus dados é a entidade do 
Grupo Telefónica vinculada ao remetente, a fim de manter o contato professional 
e administrar a relação estabelecida com o destinatário ou com a entidade à 
qual esteja vinculado. Você pode entrar em contato com o responsável do 
tratamento de dados e exercer os seus direitos escrevendo a 
privacidad@telefonica.com. Você pode 
consultar informação adicional sobre o tratamento do seus dados na nossa 
Política de 
Privacidade.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Working group adoption call for draft-ma-opsawg-ucl-acl-03

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all,

Apologies for being late on expressing my view.

I support the adoption of the draft.

After reading it, some question coming to my mind is if the users / devices 
could be defined as pertaining to more than one group. I was thinking on that 
assuming that different groups could have some common ACLs, so if maybe could 
be something interesting to declare a group with common ACLs plus another type 
of group with the differential ACLs. This could be beneficial for instance at 
the time of updating the ACLs which are common (so avoiding to update multiple 
groups instead of only one).

Thanks and apologies again for the delay on answering the poll.

Best regards

Luis

De: OPSAWG  En nombre de Adrian Farrel
Enviado el: lunes, 11 de septiembre de 2023 22:33
Para: 'Tianran Zhou' ; opsawg@ietf.org
CC: opsawg-cha...@ietf.org
Asunto: Re: [OPSAWG] Working group adoption call for draft-ma-opsawg-ucl-acl-03

Hi Tianran,

I think this is a timely piece of work that should be adopted. I commit
to further reviews if it is adopted.

A few minor comments on this version, below. Nothing that needs to be
fixed before adoption.

There is a meta-question: should the schedule model be moved out into
a separate document? It isn't necessary at this point in time (we can
continue to work on everything in one document), but given the intended
wider applicability it might be convenient to hold it in a separate
document.

Cheers,
Adrian

===

It would be good if the document title indicated (as the Abstract does)
what the document contains.  Something like...
   Management Tools for Policy-based Access Control

---

The abbreviation "UCL" is fine, but I don't like the expansion you give
in Section 2

   *  User group based ACL (UCL):  A YANG data model for policy-based
 network access control that specifies an extension to the IETF
 ACL model defined in [RFC8519].

1. It is weird to say that the UCL is a YANG model (when the ACL is
   clearly not a YANG model in its own right).
2. It is hard to make "User group based ACL" into UCL.
3. I am currently going through pain with the IESG objecting to calling
   something "the IETF foo" because "what if another one comes along?"

How about...

   *  User group based Control List (UCL) model:  A YANG data model for
 policy-based network access control that specifies an extension
 to the ACL YANG model defined in [RFC8519].

---

I think you might move the definition of NACL to Section 2 (especially
given the name of the document and its short title.

---

In section 2, the definition of endpoint includes "end user". I find
that term confusing: is "a user" a person, an application, or a device?
Actually, probably you mean "end-user", not a the user of an end :-)

---

Section 3 has...

   NACL policies may need to vary over time.  For example, companies may
   restrict (or grant) employees access to specific internal or external
   resources during work hours, while another policy is adopted during
   off-hours and weekends.

Pedantically, the example you give here is of use of different policies
over time, not actually varying the policies themselves.

---

4.1 should expand "SDN". A reference would be useful, too. References
for NAS and AAA on their first use would also be useful.

---

While this is obviously in the purview of this working group, it is
going to need some serious security review. The chairs need to make
provision for that, possibly by approaching SAAG to get a security
reviewer assigned.

From: OPSAWG mailto:opsawg-boun...@ietf.org>> On 
Behalf Of Tianran Zhou
Sent: Tuesday, September 5, 2023 2:13 AM
To: opsawg@ietf.org
Cc: opsawg-cha...@ietf.org
Subject: [OPSAWG] Working group adoption call for draft-ma-opsawg-ucl-acl-03

Hi WG,

This mail starts a two weeks working group adoption call for 
draft-ma-opsawg-ucl-acl-03
https://datatracker.ietf.org/doc/draft-ma-opsawg-ucl-acl/

Please send over your objections or supports to the mailing list.
If you object the adoption, please also give the reason, so that the authors 
can improve.
We will conclude this adoption call on Sep 20, 2023.
All your comments are welcome.

Best,
Tianran



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 confidential and privileged 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended 

[alto] ALTO WG meeting at IETF 118 in Prague

[LUIS MIGUEL CONTRERAS MURILLO]

Dear Chairs,
We would like to ask for the opportunity of having an ALTO WG meeting at IETF 
118 in order to continue working on the re-chartering items. With the recent 
proposal of moving ALTO to OPS Area [1], it seems convenient to put in that 
context the potential new work items, mostly for receiving feedback from OPS 
AD. We also see a risk on the fact that next IETF 119 in Australia could 
represent a logistic challenge for the group in terms of getting together all 
the more-active voices in the WG. Since the new WG assignment should work from 
IETF-119 on, IETF 118 in Prague presents a great opportunity to get together 
and discuss these crucial topics, due to its proximity to the location of most 
of the ALTO team members.
So, please, could you consider the opportunity of calling for an ALTO WG 
meeting in Prague? We think it is a perfect opportunity to progress the WG and 
get timely feedback from the new ADs.

Best regards

Luis (on behalf on the ALTO weekly meetings team)

[1] https://mailarchive.ietf.org/arch/msg/ietf/iydZ0V3emgjhxVitq_2CGEMo5f8/

_
Luis M. Contreras

Transport & IP Networks
Systems and Network Global Direction
Telefónica I+D / CTIO unit / Telefónica

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

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 confidential and privileged 
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


Le informamos de que el responsable del tratamiento de sus datos es la entidad 
del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el 
contacto profesional y gestionar la relación establecida con el destinatario o 
con la entidad a la que está vinculado. Puede contactar con el responsable del 
tratamiento y ejercitar sus derechos escribiendo a 
privacidad@telefonica.com. Puede 
consultar información adicional sobre el tratamiento de sus datos en nuestra 
Política de 
Privacidad.

We inform you that the data controller is the Telefónica Group entity linked to 
the sender, for the purpose of maintaining professional contact and managing 
the relationship established with the recipient or with the entity to which it 
is linked. You may contact the data controller and exercise your rights by 
writing to privacidad@telefonica.com. 
You may consult additional information on the processing of your data in our 
Privacy 
Policy.

Informamos que o responsável pelo tratamento dos seus dados é a entidade do 
Grupo Telefónica vinculada ao remetente, a fim de manter o contato professional 
e administrar a relação estabelecida com o destinatário ou com a entidade à 
qual esteja vinculado. Você pode entrar em contato com o responsável do 
tratamento de dados e exercer os seus direitos escrevendo a 
privacidad@telefonica.com. Você pode 
consultar informação adicional sobre o tratamento do seus dados na nossa 
Política de 
Privacidade.
___
alto mailing list
alto@ietf.org

[alto] Presentation of ALTO-related draft in next TVR WG meeting on Thursday

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all,

Fyi, I will present an update of draft-contreras-tvr-alto-exposure on Thursday 
in TVR meeting, in the session just before ALTO WG meeting. Those interested on 
the topic are more than welcome to attend and provide feedback.

Best regards

Luis

_
Luis M. Contreras

Transport & IP Networks
Systems and Network Global Direction
Telefónica I+D / CTIO unit / Telefónica

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

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 confidential and privileged 
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


Le informamos de que el responsable del tratamiento de sus datos es la entidad 
del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el 
contacto profesional y gestionar la relación establecida con el destinatario o 
con la entidad a la que está vinculado. Puede contactar con el responsable del 
tratamiento y ejercitar sus derechos escribiendo a 
privacidad@telefonica.com. Puede 
consultar información adicional sobre el tratamiento de sus datos en nuestra 
Política de 
Privacidad.

We inform you that the data controller is the Telefónica Group entity linked to 
the sender, for the purpose of maintaining professional contact and managing 
the relationship established with the recipient or with the entity to which it 
is linked. You may contact the data controller and exercise your rights by 
writing to privacidad@telefonica.com. 
You may consult additional information on the processing of your data in our 
Privacy 
Policy.

Informamos que o responsável pelo tratamento dos seus dados é a entidade do 
Grupo Telefónica vinculada ao remetente, a fim de manter o contato professional 
e administrar a relação estabelecida com o destinatário ou com a entidade à 
qual esteja vinculado. Você pode entrar em contato com o responsável do 
tratamento de dados e exercer os seus direitos escrevendo a 
privacidad@telefonica.com. Você pode 
consultar informação adicional sobre o tratamento do seus dados na nossa 
Política de 
Privacidade.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Richard, Qin,

Apologies for the late answer.

In the particular case of Communities, we are identifying some logical grouping 
of prefixes from end-users attached to the operator’s network. This is done 
within conventional BGP sessions. On the other hand, with BGP-LS we are 
obtaining the topological information that allows to derive the view of how 
those prefixes can be reached.

In summary, we need to maintain these two separate sessions to create the 
network and cost map for BGP community reachability. This is an interesting 
problem since a BGP community can span more than one physical location, thus 
probably new kind of cost metrics need to be elicited for characterizing the 
cost map. I think this can be an interesting work to be discussed by the WG in 
future work.

Best regards

Luis

De: Qin Wu 
Enviado el: jueves, 6 de julio de 2023 4:52
Para: Y. Richard Yang ; LUIS MIGUEL CONTRERAS MURILLO 

CC: IETF ALTO 
Asunto: RE: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 
meeting minutes and discussion working links

Hi, Richard, Luis:

发件人: alto [mailto:alto-boun...@ietf.org] 代表 Y. Richard Yang
发送时间: 2023年6月27日 21:00
收件人: LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
抄送: IETF ALTO mailto:alto@ietf.org>>
主题: Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 
meeting minutes and discussion working links



On Tue, Jun 27, 2023 at 8:33 AM Y. Richard Yang 
mailto:y...@cs.yale.edu>> wrote:
Hi Luis,

Thank you so much for starting this thread on Topic B. I feel that this is a 
crucial topic for the WG to investigate. Please see below.

On Mon, Jun 26, 2023 at 5:18 PM LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
 wrote:
Hi all,
Related to Topic B on maintenance of ALTO, as a way of summary of what has been 
discussed during the last weeks, we could have two major sub-topics:
1/ extension of ALTO to consider operational simplicity. Here fits the proposal 
of introducing BGP communities in ALTO. The rationale is that operators use BGP 
communities quite often as mechanism for applying policies and determining 
certain behaviors on the IP addresses grouped in the form of communities. This 
seems quite useful as well at the time of exposing associated information 
(metrics, topology, etc) as enabled by ALTO. An initial draft can be found 
here: https://github.com/luismcontreras/alto-bgp-communities
The plan is to generate version -01 for IETF 117.

I like this subtopic! I have adopted a view that ALTO should be divided into 2 
layers: a concept/abstraction layer and a transport layer built on top of the 
concept layer. I feel that there is great work validating the concept layer, 
for example, the concepts of distance, ranking, say in the flow director, padis 
work. For transport later, the WG can be flexible and provide multiple 
transport mechanisms. BGP communities are an excellent, well defined framework 
to serve as a transport (of both existing alto concepts/abstractions) and also 
existing networking abstractions). Good direction.

To be specific, I think it will be a worthwhile effort to look into BGP-ALTO; 
that is, how to use BGP to encode, transport and update ALTO basic information. 
It can be considered a BGP vertical slice, with BGP-LS as the lower lower 
layer. Make sense? I will add some more details to the doc.

Talk to many of you soon.

[Qin Wu] As we know, BGP-LS is used to collect the network topology data, ALTO 
is used to expose the network topology information, RFC7752 has already provided
ALTO and BGP-LS integration use case in figure 3:
 ++
 | Client |<--+
 ++   |
  |ALTO++ BGP with+-+
 ++   |  Protocol  |  ALTO  | Link-State NLRI |   BGP   |
 | Client |<--+| Server |<| Speaker |
 ++   ||| | |
  |++ +-+
 ++   |
 | Client |<--+
 ++

Figure 3: ALTO Server Using Network Topology Information

Network topology data carried in BGP-LS is modelled as node, link , prefix
ALTO network information resource is modelled as Network map, Cost map, 
property map, entity property map,
We need to explore how node, link information combing with next hop 
information, inter-AS link information carried in BGP-LS
   Is transformed into network map, cost map, property map, etc,
   I feel this is the missing pieces we take for granted, in addition, we need 
to consider how network topology can be correlated with other network data, 
e.g.,
Performance data which is related to cost map.


Richard




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 
pe

Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Richard, yes, but this is my personal view only, not sure if the rest have 
the same view. This is why I included some of the security topics in B, more 
related to the operation and maintenance of ALTO.

Thanks

Luis

De: Y. Richard Yang 
Enviado el: martes, 27 de junio de 2023 14:56
Para: LUIS MIGUEL CONTRERAS MURILLO 
CC: IETF ALTO 
Asunto: Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 
meeting minutes and discussion working links

Hi Luis,

On Tue, Jun 27, 2023 at 8:43 AM LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
 wrote:
Hi Richard,

Thanks for your comments.

Just a small comment on security. Certainly we are addressing two dimensions in 
ALTO regarding security, at least from my view. One is the security of ALTO 
itself, which I understand is part of maintenance (topic B). And the other one 
is the enablement of new services as the trusted networking case, as presented 
by Ayoub (topic C). This is at least my understanding, both are complementary 
and equally interesting to work on, for sure.

Great clarification. So the first aspect is the focus of Topic B and the second 
aspect is in Topic C. Right?

Richard





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 confidential and privileged 
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


Le informamos de que el responsable del tratamiento de sus datos es la entidad 
del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el 
contacto profesional y gestionar la relación establecida con el destinatario o 
con la entidad a la que está vinculado. Puede contactar con el responsable del 
tratamiento y ejercitar sus derechos escribiendo a 
privacidad@telefonica.com<mailto:privacidad@telefonica.com>. Puede 
consultar información adicional sobre el tratamiento de sus datos en nuestra 
Política de 
Privacidad<https://www.telefonica.com/es/telefonica-politica-de-privacidad-de-terceros/>.

We inform you that the data controller is the Telefónica Group entity linked to 
the sender, for the purpose of maintaining professional contact and managing 
the relationship established with the recipient or with the entity to which it 
is linked. You may contact the data controller and exercise your rights by 
writing to privacidad@telefonica.com<mailto:privacidad@telefonica.com>. 
You may consult additional information on the processing of your data in our 
Privacy 
Policy<https://www.telefonica.com/en/wp-content/uploads/sites/5/2022/12/Telefonica-Third-data-subjects-Privacy-Policy.pdf>.

Informamos que o responsável pelo tratamento dos seus dados é a entidade do 
Grupo Telefónica vinculada ao remetente, a fim de manter o contato professional 
e administrar a relação estabelecida com o destinatário ou com a entidade à 
qual esteja vinculado. Você pode entrar em contato com o responsável do 
tratamento de dados e exercer os seus direitos escrevendo a 
privacidad@telefonica.com<mailto:privacidad@telefonica.com>. Você pode 
consultar informação adicional sobre o tratamento do seus dados na nossa 
Política de 
Privacidade<https://www.telefonica.com/es/politica-de-privacidade-de-terceiros/>.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all,

Related to Topic B on maintenance of ALTO, as a way of summary of what has been 
discussed during the last weeks, we could have two major sub-topics:

1/ extension of ALTO to consider operational simplicity. Here fits the proposal 
of introducing BGP communities in ALTO. The rationale is that operators use BGP 
communities quite often as mechanism for applying policies and determining 
certain behaviors on the IP addresses grouped in the form of communities. This 
seems quite useful as well at the time of exposing associated information 
(metrics, topology, etc) as enabled by ALTO. An initial draft can be found 
here: https://github.com/luismcontreras/alto-bgp-communities
The plan is to generate version -01 for IETF 117.

2/ security aspects of ALTO. This has been discussed in both one of the interim 
meetings (see 
https://datatracker.ietf.org/meeting/interim-2023-alto-05/materials/slides-interim-2023-alto-05-sessa-security-aspects-regarding-alto-luis-00)
 and one ad-hoc discussion meeting 
(https://mailarchive.ietf.org/arch/msg/alto/HnhO5H5xy4hBGtfm3JI7-K9mq3Y/). The 
rationale for this activity is to improve the security around the deployment 
and operation of ALTO in production networks. As commented during the interim, 
there are a number of security issues documented so far, like:

  *   A high-level discussion of security issues in the ALTO problem statement 
[RFC5693]
  *   Unwanted information disclosure risks, as well as specific 
security-related requirements in the ALTO requirements document [RFC6708].
  *   Issues related ALTO server discovery in [RFC7286]
  *   Identified cases for ALTO deployments in [RFC7971]
  *   Security considerations in the remaining RFCs
However, new security concerns emerge from deployments, such as:

  *   Obfuscation of PIDs, and the handling of them in scenarios with multiple 
ALTO clients
  *   Mechanisms for isolation of the ALTO server from direct client interaction
  *   Secure retrieval of information from external components (e.g., probes, 
etc)
  *   etc
A potential first step could be to document these new security considerations 
and then concentrate on those not solved representing relevant threats in ALTO 
operation.

There could be other relevant topics related to the maintenance of ALTO part 
from the two commented above.

Any further ideas on this respect?

Of course for those interested on the topics above, please comment.

Thanks in advance

Best regards

Luis

De: alto  En nombre de Y. Richard Yang
Enviado el: miércoles, 21 de junio de 2023 1:47
Para: IETF ALTO 
Asunto: [alto] June 20, 2023 meeting minutes and discussion working links

Hi all,

As suggested by Ayoub, Jordi and others during the weekly meeting today, 
starting from today, the note taker will not only update the meeting minutes 
page 
(https://github.com/ietf-wg-alto/wg-materials/blob/main/meetings-ietf-alto/ietf-alto-2023.md),
 but also provide a text summary and comments, if appropriate, on the meeting. 
So below are my quick comments and the full meeting minutes are below; the 
archive is at the link above.

Regarding comments, the most important item that I, as a note taker, take away 
is the wonderful discussion about how to organize future work discussions. In 
particular, the participants divided the potential work into 4 areas, and 
created 4 github issues. We also created a common Google doc to allow 
systematic write up. The links to them are below.

In particular, the four areas and their coordinators are:
- A: Integration of data sources and their exposures; coordinator: Jordi, Luis 
and Kai
- B: Maintenance of ALTO protocol; coordinator: Luis, Richard
- C: Security and trust; coordinators: Ayoub, Junichi, Motoyoshi
- D: New architectural extensions; coordinators: Roland and Sabine

We sure can adjust the coordinators. So so, please let me know, and we can 
adjust the page. The plan is that the coordinators will closely with the chairs 
(Qin and Med) to make concrete progress. The coordinators will kick off the 
discussions.

Richard as note taker on June 20, 2023

 Meeting Minutes Text 

IETF, ALTO Meeting: June 20, 2023

Agenda:

  *   Transport and OAM documents

 *   Transport: 
https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/issues

  *   OAM: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues
  *   ALTO Future Work: 
https://mailarchive.ietf.org/arch/msg/alto/uIFD6Dhikfu4J4PYcpJTbsiXbnE/ 
https://github.com/ietf-wg-alto/wg-materials/blob/main/FutureALTO/alto-direction-of-work.md
  *   Preps for IETF 117:

 *   Drafts and presentations that the ALTO group plans to work on
 *   Agenda

  *   New revision of Green Networking Metrics draft in opsawg: 
https://datatracker.ietf.org/doc/draft-cx-opsawg-green-metrics/

Minutes

*Note taker: Richard

  *   Charter documents: transport and OAM updates

 *   OAM: Jensen and Med had a discussion on the draft and submit the 
revision to IESG. The document is now 

Re: [alto] Potential topics for Proposal #3: Support ALTO Extensions for the New Industry Needs

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all,

Some additional comments from my side, in this case regarding B and C.

In B there is for sure space for the operational matters related with ALTO, 
some of them identified so far. This would be certainly the case of security of 
ALTO as a production component within networks. But also related to maintenance 
of ALTO we can consider aspects such as the extension to using BGP communities, 
for instance. That is, progress on ALTO protocol and framework for making it 
more "operational" oriented, once we are gaining experience on it and 
identifying further needs.

In the case of C, my way of looking to it, is that ALTO can become the enabler 
of new services by means of the exploitation of properties associated to the 
network and cost maps. Trustness is a very relevant property, and certainly it 
can be a new service provided by ALTO, but additional properties could be also 
considered as we commented during the interims. So this would open a new 
dimension of ALTO which is working on properties associated to the topology and 
cost information (some examples commented during the interim were providing 
information about keys for being used in a communication, providing information 
about encryption support, etc). In summary, enabling services by leveraging on 
the exposure of properties, not only costs. Trusted topologies can be an 
initial work in this line.

Thanks Sabine and Jordi for your explanations. Hope this can serve as 
complement to yours.

Best regards

Luis

De: alto  En nombre de Jordi Ros Giralt
Enviado el: jueves, 15 de junio de 2023 12:09
Para: Sabine Randriamasy (Nokia) 
; IETF ALTO 

Asunto: Re: [alto] Potential topics for Proposal #3: Support ALTO Extensions 
for the New Industry Needs

Thanks Sabine for summarizing our conversation and initiating this thread.

Various members of the ALTO WG are taking leadership on each of these topics to 
continue productive conversations during the next weeks as we approach IETF 
117. Between now and then, the plan is to discuss the topics and then convey 
our recommendations to the Future ALTO Direction document: 
https://github.com/ietf-wg-alto/wg-materials/blob/main/FutureALTO/alto-direction-of-work.md

I would like to add comments on topics A and D.

Regarding A (new data sources), a key need is to extend the ALTO protocol to 
incorporate compute information. ALTO has a long history of exposing 
communication state information to the application starting with P2P networks 
and then CDNs. But as we move into edge computing applications, the reality is 
that communication information alone is not enough. The applications are now 
working at the intersection of compute and communication, and so to optimize 
service placement, both pieces of information are needed. A key use case is the 
transition to AI. As hyperscalers are running at capacity, it is expected that 
a fraction of AI inference workloads (and even a fraction of the training) will 
need to be offloaded to the edge devices. Some additional drivers for this 
offloading include (1) leveraging unutilized compute power available at the 
edge, (2) energy savings to lower CO2 emissions, (3) latency, (4) reliability 
and performance, and (5) privacy, security and personalization.

>From an architecture standpoint, ALTO being positioned as an API to expose 
>system information to the application is a natural fit. The group has 
>important historical expertise in this domain so it is also well positioned. 
>The group has also been hoping to add this capability on the new charter for a 
>while. For instance, the service edge draft 
>(https://datatracker.ietf.org/doc/draft-contreras-alto-service-edge/) which 
>proposes to extend ALTO with compute information to assist the selection of 
>the service edge deployment locations was initiated in late 2019, with the 
>last updates to this document presented in IETF 116. Among the other efforts, 
>the group plans to update this document in the next weeks and present it 
>during IETF 117 to help drive the conversation about compute data source 
>extensions, which fits under topic A. There is also interest in the group to 
>work with open source platforms (in particular, the Linux Foundation) to 
>plugin ALTO RFCs into running code production stacks (with edge computing 
>being also a relevant driving use case) leveraging an open source 
>implementation of ALTO (e.g., OpenALTO).

Regarding D, in particular, the scope of work in comparison with CATS, I think 
there are two elements here: (1) gaps and (2) common ground.

(1) There is work around covering gaps that are not addressed in the CATS 
charter. CATS is focusing on in-network exposure of communication and compute 
conditions to help the network operator optimize the steering of flows. The gap 
we are interested in covering from ALTO is (1) the ability to expose network 
and compute conditions to the application and (2) to support other use cases 
such as optimizing the placement of 

Re: [alto] Meeting Info for Tuesday June 13th, 2023

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all,

It will not be possible for me to connect today because of an internal.offsite 
meeting. I will sync up with the minutes later.

Sorry,

Luis

Enviado desde Outlook para Android

From: alto  on behalf of Jordi Ros Giralt 

Sent: Tuesday, June 13, 2023 1:01:29 PM
To: alto@ietf.org 
Subject: [alto] Meeting Info for Tuesday June 13th, 2023

Dear all,



This is a friendly reminder that we will have our ALTO weekly meeting today 
Tuesday, June 13th, 2023, at 9:00 am EST (3:00 pm CET and 9:00 pm Beijing Time).



Agenda:



(Please suggest new items as necessary)



- Transport and OAM documents

- Transport: 
https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/issues

  - OAM: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues

- ALTO Future Work:

https://mailarchive.ietf.org/arch/msg/alto/uIFD6Dhikfu4J4PYcpJTbsiXbnE/


https://github.com/ietf-wg-alto/wg-materials/blob/main/FutureALTO/alto-direction-of-work.md



ALTO Scrum Dashboard:

--

- https://github.com/orgs/ietf-wg-alto/projects/1/views/2



Bridge:

-

- Join from the meeting link: 
https://ietf.webex.com/ietf/j.php?MTID=m1dd555eff4634917aaff5a927d6e2c68

- Join by meeting number (access code): 2424 884 8159

- Meeting password: ymKtkapb394



ALTO Meeting Minutes:

-

https://github.com/ietf-wg-alto/wg-materials/blob/main/meetings-ietf-alto/ietf-alto-2023.md





Thanks,

Jordi, on behalf of ALTO






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 confidential and privileged 
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


Le informamos de que el responsable del tratamiento de sus datos es la entidad 
del Grupo Telef?nica vinculada al remitente, con la finalidad de mantener el 
contacto profesional y gestionar la relaci?n establecida con el destinatario o 
con la entidad a la que est? vinculado. Puede contactar con el responsable del 
tratamiento y ejercitar sus derechos escribiendo a 
privacidad@telefonica.com. Puede 
consultar informaci?n adicional sobre el tratamiento de sus datos en nuestra 
Pol?tica de 
Privacidad.

We inform you that the data controller is the Telef?nica Group entity linked to 
the sender, for the purpose of maintaining professional contact and managing 
the relationship established with the recipient or with the entity to which it 
is linked. You may contact the data controller and exercise your rights by 
writing to privacidad@telefonica.com. 
You may consult additional information on the processing of your data in our 
Privacy 
Policy.

Informamos que o respons?vel pelo tratamento dos seus dados ? a entidade do 
Grupo Telef?nica vinculada ao remetente, a fim de manter o contato professional 
e administrar a rela??o estabelecida com o destinat?rio ou com a entidade ? 
qual esteja vinculado. Voc? pode entrar em contato com o respons?vel do 
tratamento de dados e exercer os seus direitos escrevendo a 
privacidad@telefonica.com. Voc? pode 
consultar informa??o adicional sobre o tratamento do seus dados na nossa 
Pol?tica de 

Re: [alto] Meeting Info for Tuesday May 23rd, 2023

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all

It Will not be possible for me to attend today's meeting. I will sync up with 
the notes generated.

Thanks and apologies

Luis

De: alto  En nombre de Jordi Ros Giralt
Enviado el: martes, 23 de mayo de 2023 9:38
Para: alto@ietf.org
Asunto: [alto] Meeting Info for Tuesday May 23rd, 2023

Dear all,



This is a friendly reminder that we will have our ALTO weekly meeting today 
Tuesday, May 23rd, 2023, at 9:00 am EST (3:00 pm CET and 9:00 pm Beijing Time).



Agenda:



(Please suggest new items as necessary)



- Retrospective on ALTO Interim #4

- 2nd WGLC on new transport and OAM docs

- Review outstanding WGLC github tickets / pull requests:

  - Transport: 
https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/issues

  - OAM: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues

- Preparations for the forthcoming ALTO Interim (May 30th at 10am EST) Meeting 
#5.



ALTO Scrum Dashboard:

--

- https://github.com/orgs/ietf-wg-alto/projects/1/views/2



Bridge:

-

- Join from the meeting link: 
https://ietf.webex.com/ietf/j.php?MTID=m1dd555eff4634917aaff5a927d6e2c68

- Join by meeting number (access code): 2424 884 8159

- Meeting password: ymKtkapb394



ALTO Meeting Minutes:

-

https://github.com/ietf-wg-alto/wg-materials/blob/main/meetings-ietf-alto/ietf-alto-2023.md





Thanks,

Jordi, on behalf of ALTO






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 confidential and privileged 
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


Le informamos de que el responsable del tratamiento de sus datos es la entidad 
del Grupo Telef?nica vinculada al remitente, con la finalidad de mantener el 
contacto profesional y gestionar la relaci?n establecida con el destinatario o 
con la entidad a la que est? vinculado. Puede contactar con el responsable del 
tratamiento y ejercitar sus derechos escribiendo a 
privacidad@telefonica.com. Puede 
consultar informaci?n adicional sobre el tratamiento de sus datos en nuestra 
Pol?tica de 
Privacidad.

We inform you that the data controller is the Telef?nica Group entity linked to 
the sender, for the purpose of maintaining professional contact and managing 
the relationship established with the recipient or with the entity to which it 
is linked. You may contact the data controller and exercise your rights by 
writing to privacidad@telefonica.com. 
You may consult additional information on the processing of your data in our 
Privacy 
Policy.

Informamos que o respons?vel pelo tratamento dos seus dados ? a entidade do 
Grupo Telef?nica vinculada ao remetente, a fim de manter o contato professional 
e administrar a rela??o estabelecida com o destinat?rio ou com a entidade ? 
qual esteja vinculado. Voc? pode entrar em contato com o respons?vel do 
tratamento de dados e exercer os seus direitos escrevendo a 
privacidad@telefonica.com. Voc? pode 
consultar informa??o adicional sobre o tratamento do seus dados na nossa 
Pol?tica de 
Privacidade.
___
alto mailing list
alto@ietf.org

Re: [alto] Proposed Agenda for Interims #2-5

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Qiufang,

Thanks for pointing this out.

I think what you propose makes sense. Probably details should be clarified in 
terms of how PIDs defined for the measurement agents could correlate with 
conventional PIDs, i.e., those representing IP address pools. Some ideas come 
to my mind that probably we could discuss.

But yes, I see this interesting to contemplate to understand what kind of 
extensions could be derived from this scenario, certainly interesting for 
network operations.

Thanks for commenting and good to see this reported in the compilation sheet.

Best regards

Luis


De: maqiufang (A) 
Enviado el: miércoles, 26 de abril de 2023 11:12
Para: LUIS MIGUEL CONTRERAS MURILLO 
; Jensen Zhang 
; kai...@scu.edu.cn
CC: IETF ALTO ; xie...@chinatelecom.cn; wang...@chinatelecom.cn
Asunto: RE: [alto] Proposed Agenda for Interims #2-5

Hi, Luis and all

Thanks for this effort. Jensen and Kai, I think your proposals make sense to 
me, maybe could be reflected on the shared spreadsheet?

I’ve Just added one more potential data source to the spreadsheet: LMAP 
(Large-Scale Measurement of Broadband Performance, RFC7594) network measurement 
results. That said, ALTO server can simply work as the LMAP collector and 
accept the report from the measurement agent which performs the measurement 
tasks as instructed by the LMAP controller.

PS. There is a draft 
(https://www.ietf.org/archive/id/draft-xie-alto-lmap-00.txt) related to that, 
the authors plan to revive it very soon.

Best Regards,
Qiufang

From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Jensen Zhang
Sent: Wednesday, April 26, 2023 8:29 AM
To: kai...@scu.edu.cn<mailto:kai...@scu.edu.cn>
Cc: IETF ALTO mailto:alto@ietf.org>>; Qin Wu 
mailto:bill...@huawei.com>>
Subject: Re: [alto] Proposed Agenda for Interims #2-5

Hi Luis and all,

Thanks for this useful collection of data sources. Besides the data sources 
listed in this collection, I am wondering if the following kinds of data 
sources can also be considered:

1. Prefix information, e.g., internet routing registry (IRR). It provides route 
and provider related information attached to IP prefixes. It may be helpful for 
network/property map generation, or locating the network domain in multidomain 
settings.

2. Data plane information, e.g., routing and forwarding tables read from BGP 
looking glass server or other OAM tools. Although I see the "IETF TE Network 
topology" source can already provide routing information, it may focus on the 
control plane, e.g., routing policy, not the data plane.

3. Telemetry information, e.g., traceroute. It can get both routing and 
performance information. It may have some overlap with the performance metrics.

Looking forward to seeing more discussions on this topic.

Best,
Jensen

On Tue, Apr 25, 2023 at 10:55 PM mailto:kai...@scu.edu.cn>> 
wrote:

Hi Luis and all,



Thanks for the effort. The information is really useful and comprehensive. I 
think it lays a very good foundation to discuss and proceed with potential ALTO 
extensions.



With the rationale that, in my opinion, sets the expectations for each data 
source, I am wondering whether it is beneficial to discuss gaps and constraints 
as well.



For example, I used to work on providing ALTO maps using SDN, or more 
precisely, using Open Daylight. Open Daylight has very good (among the best 
AFAIK) YANG support and the topology models were already support a few years 
back. One problem, however, was that using the topology information alone 
cannot generate high-precision network map or cost map: you still need to know 
where the hosts are attached and what is the routing. Thus, it has to be 
combined with other data sources, for example, host tracker in the SDN case or 
BGP/BGP-LS in provider networks, or be limited to specific networks, for 
example, those using link state routing protocols.



I am not saying that the document should summarize the gaps and/or constraints 
of all the data sources. Rather, I feel that the topic might be a useful input 
to the interim meeting and to future ALTO extensions.



Best,

Kai


-----Original Messages
From:"LUIS MIGUEL CONTRERAS MURILLO" 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
Sent Time:2023-04-18 06:23:51 (Tuesday)
To: "mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>" 
mailto:mohamed.boucad...@orange.com>>, "IETF 
ALTO" mailto:alto@ietf.org>>
Cc: "Qin Wu" mailto:bill...@huawei.com>>
Subject: Re: [alto] Proposed Agenda for Interims #2-5
Hi Med, Qin, WG,

In order to provide inputs for:


* interim #3: Deployment Catalysts

• Proposals to fix the integration complexity and integration with data 
sources

Jordi and I have been working on collecting some references that we consider as 
potential data sources of relevance for the WG and possible integration with 
ALTO. We have collected those inputs here: 
http

Re: [alto] Proposed Agenda for Interims #2-5

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Jensen,

Thanks for your comment.

Please, see my answer in line.

Thank you,

Luis

De: Jensen Zhang 
Enviado el: miércoles, 26 de abril de 2023 2:29
Para: kai...@scu.edu.cn
CC: LUIS MIGUEL CONTRERAS MURILLO ; 
IETF ALTO ; Qin Wu 
Asunto: Re: [alto] Proposed Agenda for Interims #2-5

Hi Luis and all,

Thanks for this useful collection of data sources. Besides the data sources 
listed in this collection, I am wondering if the following kinds of data 
sources can also be considered:

1. Prefix information, e.g., internet routing registry (IRR). It provides route 
and provider related information attached to IP prefixes. It may be helpful for 
network/property map generation, or locating the network domain in multidomain 
settings.

[[Luis>]] This can be a useful information to add if different policies apply 
to different administrative domains. I think it could be used for map filtering 
purposes (as described in section 4.1.2 of RFC 7285). For instance thinking on 
the pilot we are doing in Telefonica for integrating ALTO with the Telefonica 
CDN, this property could be used for deciding from which streamer send the 
content to external prefixes of subscribers sitting in ISPs different from 
Telefonica.


2. Data plane information, e.g., routing and forwarding tables read from BGP 
looking glass server or other OAM tools. Although I see the "IETF TE Network 
topology" source can already provide routing information, it may focus on the 
control plane, e.g., routing policy, not the data plane.

[[Luis>]] Not 100% clear to me this point (i.e., your reference to data plane). 
So my answer could not be exactly addressing your question. In my view, 
relaying on tools like BGP looking glass can certainly provide information 
about reachability of prefixes, especially in multi-domain settings where there 
is no possibility of retrieving such information e.g. for another ALTO server. 
So it can help to infer some notion of cost map for a given point in time in 
relation with some IP prefixes. The best would be probably to pair with the 
corresponding ALTO server for that domain for getting the information directly, 
but if this is not possible, BGP looking glass could be certainly an 
alternative for indirectly obtaining such information.

3. Telemetry information, e.g., traceroute. It can get both routing and 
performance information. It may have some overlap with the performance metrics.

[[Luis>]] As before, it would be preferible to pair with corresponding ALTO 
servers for this. If not possible, that could be a way of inferring 
performance, which is somehow similar to what most of the applications make 
today for taking their own service decisions (I mean, inferring behaviors from 
performance metrics observed by their own).


Looking forward to seeing more discussions on this topic.

Best,
Jensen

On Tue, Apr 25, 2023 at 10:55 PM mailto:kai...@scu.edu.cn>> 
wrote:

Hi Luis and all,



Thanks for the effort. The information is really useful and comprehensive. I 
think it lays a very good foundation to discuss and proceed with potential ALTO 
extensions.



With the rationale that, in my opinion, sets the expectations for each data 
source, I am wondering whether it is beneficial to discuss gaps and constraints 
as well.



For example, I used to work on providing ALTO maps using SDN, or more 
precisely, using Open Daylight. Open Daylight has very good (among the best 
AFAIK) YANG support and the topology models were already support a few years 
back. One problem, however, was that using the topology information alone 
cannot generate high-precision network map or cost map: you still need to know 
where the hosts are attached and what is the routing. Thus, it has to be 
combined with other data sources, for example, host tracker in the SDN case or 
BGP/BGP-LS in provider networks, or be limited to specific networks, for 
example, those using link state routing protocols.



I am not saying that the document should summarize the gaps and/or constraints 
of all the data sources. Rather, I feel that the topic might be a useful input 
to the interim meeting and to future ALTO extensions.



Best,

Kai



-Original Messages
From:"LUIS MIGUEL CONTRERAS MURILLO" 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
Sent Time:2023-04-18 06:23:51 (Tuesday)
To: "mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>" 
mailto:mohamed.boucad...@orange.com>>, "IETF 
ALTO" mailto:alto@ietf.org>>
Cc: "Qin Wu" mailto:bill...@huawei.com>>
Subject: Re: [alto] Proposed Agenda for Interims #2-5
Hi Med, Qin, WG,

In order to provide inputs for:


* interim #3: Deployment Catalysts

• Proposals to fix the integration complexity and integration with data 
sources

Jordi and I have been working on collecting some references that we consider as 
potential data sources of relevance for the WG and possible integ

Re: [alto] Proposed Agenda for Interims #2-5

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Kai,

You are touching relevant points.

First, regarding the idea of retrieving the topology from the controller. In 
the simpler case, since the controller will already have a topology processed 
from the information retrieved from the network, it can make sense to get it 
from the controller. So, ALTO can benefit from that, thus avoiding to process 
twice the same information. In the more complex situation, to could be the case 
that the SDN controller collects and aggregates information from different 
domains (even under the same administrative responsibility) then simplifying 
again the aggregation and processing of the overall topological information. Or 
even it could be the case where the SDN controllers builds a general view of a 
network leveraging partial views even collected through different protocols 
(e.g., BGP-LS, LLDP, etc). In summary, the benefit could come from simplifying 
the ALTO server processes, just retrieving what has been already aggregated and 
processed.

However it is important what you say. Not all the information could be on the 
topology provided by the SDN controller. For instance, the subnets (IP 
prefixes) representing e.g. residential broadband users which are attached to 
border routers are not present in IETF Network Topology. These subnets should 
be obtained by means of BGP sessions with the route reflectors in the network.

So, even though we can simplify the process of the ALTO server by retrieving 
the internals of the network from the controller (which is useful for building 
the cost map) we yet need to maintain BGP sessions with the RR for 
understanding the IP pools in each PIC (i.e. to build the network map).

Finally going to your question about if it is useful to discuss gaps and 
constraints, my answer id definitely YES.

Thanks so much for your comment,

Luis

De: kai...@scu.edu.cn 
Enviado el: martes, 25 de abril de 2023 16:55
Para: LUIS MIGUEL CONTRERAS MURILLO 
CC: mohamed.boucad...@orange.com; IETF ALTO ; Qin Wu 

Asunto: Re: Re: [alto] Proposed Agenda for Interims #2-5


Hi Luis and all,



Thanks for the effort. The information is really useful and comprehensive. I 
think it lays a very good foundation to discuss and proceed with potential ALTO 
extensions.



With the rationale that, in my opinion, sets the expectations for each data 
source, I am wondering whether it is beneficial to discuss gaps and constraints 
as well.



For example, I used to work on providing ALTO maps using SDN, or more 
precisely, using Open Daylight. Open Daylight has very good (among the best 
AFAIK) YANG support and the topology models were already support a few years 
back. One problem, however, was that using the topology information alone 
cannot generate high-precision network map or cost map: you still need to know 
where the hosts are attached and what is the routing. Thus, it has to be 
combined with other data sources, for example, host tracker in the SDN case or 
BGP/BGP-LS in provider networks, or be limited to specific networks, for 
example, those using link state routing protocols.



I am not saying that the document should summarize the gaps and/or constraints 
of all the data sources. Rather, I feel that the topic might be a useful input 
to the interim meeting and to future ALTO extensions.



Best,

Kai



-Original Messages
From:"LUIS MIGUEL CONTRERAS MURILLO" 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
Sent Time:2023-04-18 06:23:51 (Tuesday)
To: "mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>" 
mailto:mohamed.boucad...@orange.com>>, "IETF 
ALTO" mailto:alto@ietf.org>>
Cc: "Qin Wu" mailto:bill...@huawei.com>>
Subject: Re: [alto] Proposed Agenda for Interims #2-5
Hi Med, Qin, WG,

In order to provide inputs for:


* interim #3: Deployment Catalysts

• Proposals to fix the integration complexity and integration with data 
sources

Jordi and I have been working on collecting some references that we consider as 
potential data sources of relevance for the WG and possible integration with 
ALTO. We have collected those inputs here: 
https://docs.google.com/spreadsheets/d/1P4GrhQz_t17jIWg-3b1ycldhBWEEgIAAUZe2vjeO_1U/edit#gid=0

Please, feel free to access and check, all of you should be able to add/drop 
comments as well (let me know in case you need some permission for that). In 
the table we cover potential data sources, the rationale for considering them, 
existing reference work, as well as impacts on current ALTO. We hope this could 
be a basis for discussion for interim #3, but also to trigger discussions on 
the mailing list so we as WG can go to the interim with a more clear notion of 
the data sources and their implications.

Thanks

Best regards

Luis


De: alto mailto:alto-boun...@ietf.org>> En nombre de 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
Enviado el: martes, 4 de abril de 2023 8:58
Pa

Re: [alto] Reminder ALTO interim meeting today at 10am EST (not 9am)

[LUIS MIGUEL CONTRERAS MURILLO]

Thanks Med

(adding also in cc ALTO mailing list).

I have gone through the suggested changes producing a -01 version, yet open for 
comments and discussion. I attach the txt file for your convenience (the diff 
with the published one is easily generated with IETF authors tools).

I have also created a github space for the draft, here: 
https://github.com/luismcontreras/alto-bgp-communities

Best regards

Luis

De: mohamed.boucad...@orange.com 
Enviado el: miércoles, 12 de abril de 2023 16:49
Para: Qin Wu ; Jordi Ros Giralt ; Y. 
Richard Yang ; Jensen Zhang ; 
kai...@scu.edu.cn; Lachlan Keller ; LUIS MIGUEL 
CONTRERAS MURILLO ; Randriamasy, 
Sabine (Nokia - FR/Paris-Saclay) ; 
maqiufang (A) ; ayoub.mess...@fujitsu.com; Motoyoshi 
Sekiya (Fujitsu) ; Chongfeng Xie 
; Cheng Zhou 
Asunto: RE: Reminder ALTO interim meeting today at 10am EST (not 9am)

Hi all,

FWIW, some additional comments on the BGP communities proposal can be seen at 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-contreras-alto-bgp-communities-00-rev%20Med.doc

Cheers,
Med

De : Qin Wu mailto:bill...@huawei.com>>
Envoyé : mardi 11 avril 2023 17:21
À : Jordi Ros Giralt mailto:j...@qti.qualcomm.com>>; Y. 
Richard Yang mailto:y...@cs.yale.edu>>; Jensen Zhang 
mailto:jingxuan.n.zh...@gmail.com>>; 
kai...@scu.edu.cn<mailto:kai...@scu.edu.cn>; Lachlan Keller 
mailto:lachlan.kel...@yale.edu>>; LUIS MIGUEL 
CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>;
 Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>;
 maqiufang (A) mailto:maqiufa...@huawei.com>>; 
ayoub.mess...@fujitsu.com<mailto:ayoub.mess...@fujitsu.com>; Motoyoshi Sekiya 
(Fujitsu) mailto:sekiya.motoy...@fujitsu.com>>; 
Chongfeng Xie mailto:xie...@chinatelecom.cn>>; Cheng 
Zhou mailto:zhoucheng...@chinamobile.com>>
Cc : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Objet : RE: Reminder ALTO interim meeting today at 10am EST (not 9am)

Thank all for participanting the discussion of ALTO interim meeting.
For ALTO OAM and New transport, please keeping on engaging with directorate 
reviewers who raised major issues and make sure all these major issues are 
addressed and related discussion transparent to the ALTO list.

For the next interim meeting plan, we will discuss Deployment Catalyst. 
Unfortunately we run out of time due to accident at the beginning of the 
interim meeting.
I believe the following drafts will be good input to the discussion. I made 
some of comments on these drafts,
Hope these remarks and comments help you understand the direction we suggested.

YANG Data Model for BGP-LS protocol
https://datatracker.ietf.org/doc/rfc7752/
https://datatracker.ietf.org/doc/rfc9085/
https://datatracker.ietf.org/doc/rfc9351/
https://datatracker.ietf.org/doc/rfc8571/
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-sr-policy/
https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ls-te-path-00.txt
Comment: Need to figure how this work is related to or decoupled from ALTO OAM

Extending ALTO by using BGP Communities
Comments:
How many BGP communities do we need to support?
e.g., Route Target Community, Route Origin Community
How BGP Communities can be encoded?
How BGP Communities are different from PID?

ALTO for Querying LMAP Results
https://www.ietf.org/archive/id/draft-xie-alto-lmap-00.txt

How Network Topology data collected using NETCONF/YANG can be translated into 
ALTO Network Map, Cost Map, Endpoint Map?
https://www.ietf.org/archive/id/draft-hzx-alto-network-topo-00.txt

-Qin/Med
发件人: alto [mailto:alto-boun...@ietf.org] 代表 Jordi Ros Giralt
发送时间: 2023年4月11日 19:31
收件人: alto@ietf.org<mailto:alto@ietf.org>
主题: [alto] Reminder ALTO interim meeting today at 10am EST (not 9am)

Hello ALTOers,

Just a reminder that we will be meeting today Tuesday at 10am EST for the ALTO 
interim #3 meeting. The focus of this meeting is on "WGLC follow-up of 
OAM/Transport I-Ds":

- Remote instructions: 
https://meetings.conf.meetecho.com/interim/?short=a6c2968d-b9f9-4ea7-b856-c1ee2e64e0c7
- Agenda 
https://datatracker.ietf.org/meeting/interim-2023-alto-02/materials/agenda-interim-2023-alto-02-alto-01-00
- Session materials: 
https://datatracker.ietf.org/meeting/interim-2023-alto-02/session/alto

Note that at 9am EST we have our usual ALTO weekly meeting. However, today's 
important meeting is the interim, held at 10am EST. So let me suggest that we 
skip the 9am call so we can all focus on the 10am call. I will join the 9am 
call in case anyone needs to be reminded about the 10am interim meeting.

Below you will also find the agendas for the forthcoming interim meetings as 
proposed by the chairs:


* interim #2: WGLC follow-up of OAM/Transport I-Ds

* interim #3: Deployment Catalysts

• Reuse existing network resources to identify ALTO resources (e.g., 
BGP communities)

• Proposals

[alto] RV: Reminder ALTO interim meeting today at 10am EST (not 9am)

[LUIS MIGUEL CONTRERAS MURILLO]

(Resending to ALTO mailing list solely, since it seems there was some problem 
for having the mail there due to the number of recipients in the mail)

Thanks Med

(adding also in cc ALTO mailing list).

I have gone through the suggested changes producing a -01 version, yet open for 
comments and discussion. I attach the txt file for your convenience (the diff 
with the published one is easily generated with IETF authors tools).

I have also created a github space for the draft, here: 
https://github.com/luismcontreras/alto-bgp-communities

Best regards

Luis

De: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 
mailto:mohamed.boucad...@orange.com>>
Enviado el: miércoles, 12 de abril de 2023 16:49
Para: Qin Wu mailto:bill...@huawei.com>>; Jordi Ros Giralt 
mailto:j...@qti.qualcomm.com>>; Y. Richard Yang 
mailto:y...@cs.yale.edu>>; Jensen Zhang 
mailto:jingxuan.n.zh...@gmail.com>>; 
kai...@scu.edu.cn<mailto:kai...@scu.edu.cn>; Lachlan Keller 
mailto:lachlan.kel...@yale.edu>>; LUIS MIGUEL 
CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>;
 Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>;
 maqiufang (A) mailto:maqiufa...@huawei.com>>; 
ayoub.mess...@fujitsu.com<mailto:ayoub.mess...@fujitsu.com>; Motoyoshi Sekiya 
(Fujitsu) mailto:sekiya.motoy...@fujitsu.com>>; 
Chongfeng Xie mailto:xie...@chinatelecom.cn>>; Cheng 
Zhou mailto:zhoucheng...@chinamobile.com>>
Asunto: RE: Reminder ALTO interim meeting today at 10am EST (not 9am)

Hi all,

FWIW, some additional comments on the BGP communities proposal can be seen at 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-contreras-alto-bgp-communities-00-rev%20Med.doc

Cheers,
Med

De : Qin Wu mailto:bill...@huawei.com>>
Envoyé : mardi 11 avril 2023 17:21
À : Jordi Ros Giralt mailto:j...@qti.qualcomm.com>>; Y. 
Richard Yang mailto:y...@cs.yale.edu>>; Jensen Zhang 
mailto:jingxuan.n.zh...@gmail.com>>; 
kai...@scu.edu.cn<mailto:kai...@scu.edu.cn>; Lachlan Keller 
mailto:lachlan.kel...@yale.edu>>; LUIS MIGUEL 
CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>;
 Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>;
 maqiufang (A) mailto:maqiufa...@huawei.com>>; 
ayoub.mess...@fujitsu.com<mailto:ayoub.mess...@fujitsu.com>; Motoyoshi Sekiya 
(Fujitsu) mailto:sekiya.motoy...@fujitsu.com>>; 
Chongfeng Xie mailto:xie...@chinatelecom.cn>>; Cheng 
Zhou mailto:zhoucheng...@chinamobile.com>>
Cc : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Objet : RE: Reminder ALTO interim meeting today at 10am EST (not 9am)

Thank all for participanting the discussion of ALTO interim meeting.
For ALTO OAM and New transport, please keeping on engaging with directorate 
reviewers who raised major issues and make sure all these major issues are 
addressed and related discussion transparent to the ALTO list.

For the next interim meeting plan, we will discuss Deployment Catalyst. 
Unfortunately we run out of time due to accident at the beginning of the 
interim meeting.
I believe the following drafts will be good input to the discussion. I made 
some of comments on these drafts,
Hope these remarks and comments help you understand the direction we suggested.

YANG Data Model for BGP-LS protocol
https://datatracker.ietf.org/doc/rfc7752/
https://datatracker.ietf.org/doc/rfc9085/
https://datatracker.ietf.org/doc/rfc9351/
https://datatracker.ietf.org/doc/rfc8571/
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-sr-policy/
https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ls-te-path-00.txt
Comment: Need to figure how this work is related to or decoupled from ALTO OAM

Extending ALTO by using BGP Communities
Comments:
How many BGP communities do we need to support?
e.g., Route Target Community, Route Origin Community
How BGP Communities can be encoded?
How BGP Communities are different from PID?

ALTO for Querying LMAP Results
https://www.ietf.org/archive/id/draft-xie-alto-lmap-00.txt

How Network Topology data collected using NETCONF/YANG can be translated into 
ALTO Network Map, Cost Map, Endpoint Map?
https://www.ietf.org/archive/id/draft-hzx-alto-network-topo-00.txt

-Qin/Med
发件人: alto [mailto:alto-boun...@ietf.org] 代表 Jordi Ros Giralt
发送时间: 2023年4月11日 19:31
收件人: alto@ietf.org<mailto:alto@ietf.org>
主题: [alto] Reminder ALTO interim meeting today at 10am EST (not 9am)

Hello ALTOers,

Just a reminder that we will be meeting today Tuesday at 10am EST for the ALTO 
interim #3 meeting. The focus of this meeting is on "WGLC follow-up of 
OAM/Transport I-Ds":

- Remote instructions: 
https://meetings.conf.meetecho.com/interim/?short=a6c2968d-b9f9-4ea7-b856-c1ee2e64e0c7
- Agenda 
https://datatracker.ietf.org/meeting/interim-2023-alto

Re: [alto] Proposed Agenda for Interims #2-5

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Med, Qin, WG,

In order to provide inputs for:


* interim #3: Deployment Catalysts

* Proposals to fix the integration complexity and integration with data 
sources

Jordi and I have been working on collecting some references that we consider as 
potential data sources of relevance for the WG and possible integration with 
ALTO. We have collected those inputs here: 
https://docs.google.com/spreadsheets/d/1P4GrhQz_t17jIWg-3b1ycldhBWEEgIAAUZe2vjeO_1U/edit#gid=0

Please, feel free to access and check, all of you should be able to add/drop 
comments as well (let me know in case you need some permission for that). In 
the table we cover potential data sources, the rationale for considering them, 
existing reference work, as well as impacts on current ALTO. We hope this could 
be a basis for discussion for interim #3, but also to trigger discussions on 
the mailing list so we as WG can go to the interim with a more clear notion of 
the data sources and their implications.

Thanks

Best regards

Luis


De: alto  En nombre de mohamed.boucad...@orange.com
Enviado el: martes, 4 de abril de 2023 8:58
Para: IETF ALTO 
CC: Qin Wu 
Asunto: [alto] Proposed Agenda for Interims #2-5

Hi all,

Please find below the proposed agenda for the forthcoming interims

* interim #2: WGLC follow-up of OAM/Transport I-Ds
* interim #3: Deployment Catalysts

  *   Reuse existing network resources to identify ALTO resources (e.g., BGP 
communities)
  *   Proposals to fix the integration complexity and integration with data 
sources
* interim #4: OAM/Transport I-Ds
* interim #5: Deployment Catalysts

  *   Security/privacy isolation

Comments and suggestions are welcome.

Cheers,
Qin & Med


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.



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 confidential and privileged 
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

Re: [alto] [Cats] DMDTF and CATS Metrics

[LUIS MIGUEL CONTRERAS MURILLO]

(Adding ALTO in cc since discussion on metrics is also relevant for that WG)

Hi Adrian, Dean,

Another reference work we can consider is 
https://www.rfc-editor.org/rfc/rfc7666.html. This RFC provides several metrics 
as part of the MIB definition that could be leveraged on.

Apart from that, I think we need to look at what current cloud / VI managers 
provide nowadays in terms of metrics (i.e., OpenStack, Kubernetes, etc) since 
the metrics that we could handle will be generated most probably for those 
non-IETF components. So a good exercise to start with would be to check and 
compare what kind of metrics these kind of sustems provide nowadays, and derive 
from that a common / abstract set of metrics that could be consumed by both 
CATS and ALTO.

In https://www.ietf.org/archive/id/draft-contreras-alto-service-edge-07.txt 
there is reference as well to CNTT and Anuket efforts, which probably need to 
be revisited and updated.

All in all, an exercise of collecting different sources is needed, and from 
that select relevant metrics for the purposes of ALTO and CATS.

Best regards

Luis


De: Cats  En nombre de Adrian Farrel
Enviado el: viernes, 7 de abril de 2023 20:17
Para: 'Dean Bogdanovic' 
CC: c...@ietf.org
Asunto: Re: [Cats] DMDTF and CATS Metrics

Ah, thanks Dean.

Interesting coincidence of acronyms.

This work does, indeed, look relevant.

Cheers,
Adrian

From: Dean Bogdanovic mailto:falk...@mac.com>>
Sent: 07 April 2023 19:01
To: Adrian Farrel mailto:adr...@olddog.co.uk>>
Cc: c...@ietf.org
Subject: Re: DMDTF and CATS Metrics

Hi,

I was referring to the work that is being done by Redfish and has been 
presented at IETF 98 by Joe White 
(https://datatracker.ietf.org/meeting/98/materials/slides-98-rtgwg-yang-device-profile-for-redfish-network-management-draft-wbl-rtgwg-baseline-switch-model-draft-wbl-rtgwg-yang-ci-profile-bkgd-00).
 This work didn’t continue within the IETF, but Redfish has published and keeps 
developing and maintaining their data model 
(https://www.dmtf.org/sites/default/files/standards/documents/DSP0268_2022.2.pdf].
 They did lot of compute resource modeling and taking a loot at their work is 
very useful IMO. DMTF folks know lot about compute, so it might be worth even 
rekindling the joint work.

Dean

On Apr 7, 2023, at 12:34 PM, Adrian Farrel 
mailto:adr...@olddog.co.uk>> wrote:

Hi all,

In the meeting in Yokohama, Dean Bogdanovic mentioned a presentation from
IETF-98 that might be relevant to our metrics works.

I did some digging and found the presentation by the IEEE 802.3cf - YANG
Data Model Definitions Task Force. The purpose of that work was to migrate
relevant MIB modules to YANG.

The slides for that session are at
https://datatracker.ietf.org/meeting/98/materials/slides-98-netmod-sessa-iee
e-8023cf-yang-data-model-definitions-task-force-00
The presentation is at https://youtu.be/hUSx_Ua3MnY?t=3326 and the presenter
was Rob Wilton who would, I'm sure, be responsive to questions.

I'm not clear how much this is relevant.

Dean, was that the presentation you were referring to?

Cheers,
Adrian






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 confidential and privileged 
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

Re: [alto] Reminder ALTO interim meeting today at 10am EST (not 9am)

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Jordi,

Fine for me to skip regular call and meet altogether at interim call.

Best regards

Luis

De: alto  En nombre de Jordi Ros Giralt
Enviado el: martes, 11 de abril de 2023 13:31
Para: alto@ietf.org
Asunto: [alto] Reminder ALTO interim meeting today at 10am EST (not 9am)

Hello ALTOers,

Just a reminder that we will be meeting today Tuesday at 10am EST for the ALTO 
interim #3 meeting. The focus of this meeting is on "WGLC follow-up of 
OAM/Transport I-Ds":

- Remote instructions: 
https://meetings.conf.meetecho.com/interim/?short=a6c2968d-b9f9-4ea7-b856-c1ee2e64e0c7
- Agenda 
https://datatracker.ietf.org/meeting/interim-2023-alto-02/materials/agenda-interim-2023-alto-02-alto-01-00
- Session materials: 
https://datatracker.ietf.org/meeting/interim-2023-alto-02/session/alto

Note that at 9am EST we have our usual ALTO weekly meeting. However, today's 
important meeting is the interim, held at 10am EST. So let me suggest that we 
skip the 9am call so we can all focus on the 10am call. I will join the 9am 
call in case anyone needs to be reminded about the 10am interim meeting.

Below you will also find the agendas for the forthcoming interim meetings as 
proposed by the chairs:


* interim #2: WGLC follow-up of OAM/Transport I-Ds

* interim #3: Deployment Catalysts

* Reuse existing network resources to identify ALTO resources (e.g., 
BGP communities)

* Proposals to fix the integration complexity and integration with data 
sources

* interim #4: OAM/Transport I-Ds

* interim #5: Deployment Catalysts

* Security/privacy isolation

Thanks,
Jordi on behalf of ALTO WG



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 confidential and privileged 
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

Re: [alto] WGLC for draft-ietf-alto-new-transport (Ends 28/03/2023)

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all,

Again, apologies for my late response.

I do support the progress of this document.

Just one single comment, on security considerations. The ALTO server can have 
multiple ALTO clients consuming the same updates. Section 9.1 states that "an 
ALTO client might create an unreasonable number of TIPS views". However, in 
situations where can exist multiple clients, even reasonable number of TIPS 
views can deal to Denial-of-Service Attacks if the number of clients is large. 
So maybe it could be advisable to limit the number of simultaneous ALTO clients 
and/or properly dimensioning the number of simultaneous ALTO clients to prevent 
DoS attacks by attackers that could create an insane number of clients with 
that purpose (e.g., sharing clients among instances, limiting the number of - 
total - requests, etc).

Best regards

Luis

De: mohamed.boucad...@orange.com 
Enviado el: miércoles, 15 de marzo de 2023 7:56
Para: LUIS MIGUEL CONTRERAS MURILLO 
; Qin Wu 
; IETF ALTO 
CC: ALTO Working Group 
Asunto: RE: WGLC for draft-ietf-alto-new-transport (Ends 28/03/2023)

Hi Luis,

Yes, you are right. The correct link is: 
https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07.

Cheers,
Med

De : alto mailto:alto-boun...@ietf.org>> De la part de 
LUIS MIGUEL CONTRERAS MURILLO
Envoyé : mardi 14 mars 2023 23:23
À : Qin Wu 
mailto:bill.wu=40huawei@dmarc.ietf.org>>;
 IETF ALTO mailto:alto@ietf.org>>
Cc : ALTO Working Group mailto:alto-cha...@ietf.org>>
Objet : Re: [alto] WGLC for draft-ietf-alto-new-transport (Ends 28/03/2023)

Hi Qin

The link provided redirects to 
https://datatracker.ietf.org/doc/html/draft-ietf-alto-oam-yang-06 instead of 
new transport draft. I assume the subject is correct and the WG LC is against 
new transport, correct? Just to be dure and reviewing the correct draft to 
answer this LC.

Thanks

Luis

De: alto mailto:alto-boun...@ietf.org>> En nombre de Qin 
Wu
Enviado el: martes, 14 de marzo de 2023 2:06
Para: IETF ALTO mailto:alto@ietf.org>>
CC: ALTO Working Group mailto:alto-cha...@ietf.org>>
Asunto: [alto] WGLC for draft-ietf-alto-new-transport (Ends 28/03/2023)


Hi, All

This message starts 2 weeks WGLC for 
https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07<https://datatracker.ietf.org/doc/html/draft-ietf-alto-oam-yang-06>.
 The call ends: 28/03/2023.



Please review and indicate your support or objection to proceed with the 
publication of this document.



Thank you.



Cheers,

Med & Qin




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 confidential and privileged 
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

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this 

Re: [alto] WGLC for draft-ietf-alto-oam-yang (Ends 26/03/2023)

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all,

My apologies for answering late to this WGLC.

I do support the progress of this document.

I have some few comments:

  *   Figure 1: it is not clear the direction of the arrows, specially where 
"report" is written, probably missing some "+" symbol. Please, review and 
clarify if needed.
  *   Stats parameters of ALTO. There are some global stat values, but there is 
no reference for the time in which those values have been collected (the total 
time in which the ALTO server is being up and running). Note that for the 
"last-stats" the time reference is 5 min, but for the absolute stats there is 
no time reference.
  *   Question. Regarding the number of PIDs I understand it is possible to 
retrieve the total number of PIDs in ALTO. Not sure if it would be meaningful 
to have the number of PIDs for filtered maps. Not sure if this can be relevant, 
maybe yes.

Thanks so much and apologies again for the time taken in answering (IETF 
absorbed most of my time before and during IETF week).

Best regards

Luis

De: alto  En nombre de mohamed.boucad...@orange.com
Enviado el: martes, 21 de marzo de 2023 15:30
Para: alto@ietf.org; draft-ietf-alto-oam-y...@ietf.org
CC: alto-cha...@ietf.org
Asunto: Re: [alto] WGLC for draft-ietf-alto-oam-yang (Ends 26/03/2023)

Hi all,

This is a gentle reminder that this WGLC is still running.

Silence does not mean that the document is in good shape. So, please review and 
share your comments. If you are happy with the current version, that's also a 
good feedback we would like to hear.

FWIW, there are:


  *   5 Closed WGLC PRs: 
https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/pulls?q=is%3Apr+is%3Aclosed+label%3AWGLC
  *   2 Closed WGLC Issues: 
https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues?q=is%3Aissue+is%3Aclosed+label%3AWGLC
  *   9 Open WGLC Issues: 
https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues?q=is%3Aissue+is%3Aopen+label%3AWGLC

Thank you.

Cheers,
Qin & Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : dimanche 12 mars 2023 19:42
À : 'alto@ietf.org' mailto:alto@ietf.org>>; 
'draft-ietf-alto-oam-y...@ietf.org' 
mailto:draft-ietf-alto-oam-y...@ietf.org>>
Cc : 'alto-cha...@ietf.org' mailto:alto-cha...@ietf.org>>
Objet : RE: WGLC for draft-ietf-alto-oam-yang (Ends 26/03/2023)

Re-,

FWIW, issues/PRs may be also raised using the github repo. Please use "WGLC" 
label when entering your items.

The current active WGLC comments can be seen at: 
https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues?q=is%3Aissue+is%3Aopen+label%3AWGLC

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : dimanche 12 mars 2023 19:23
À : alto@ietf.org; 'draft-ietf-alto-oam-y...@ietf.org' 
mailto:draft-ietf-alto-oam-y...@ietf.org>>
Cc : alto-cha...@ietf.org
Objet : WGLC for draft-ietf-alto-oam-yang (Ends 26/03/2023)

Hi all,

This message starts the WGLC for 
https://datatracker.ietf.org/doc/html/draft-ietf-alto-oam-yang-06. The call 
ends: 26/03/2023.

Please review and indicate your support or objection to proceed with the 
publication of this document.

Thank you.

Cheers,
Qin & Med

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.



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 confidential and privileged 
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, 

[alto] ALTO and TVR

[LUIS MIGUEL CONTRERAS MURILLO]

Dear all,

This is just to remind you that tomorrow in TVR there will be a presentation 
that concerns ALTO WG. I will present "Using ALTO for Exposing Time-Variant 
Routing Information" 
(https://datatracker.ietf.org/doc/draft-contreras-tvr-alto-exposure/) which 
proposes how ALTO cost calendar could be used for TVR exposure to applications. 
Initial ideas for work in TVR and ALTO are identified, which can be useful as 
input for ALTO in the future (as long as TVR is getting mature).

Bets regards

Luis

_
Luis M. Contreras

Transport & IP Networks
Systems and Network Global Direction
Telefónica I+D / CTIO unit / Telefónica

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

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 confidential and privileged 
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

Re: [alto] Discussion on the future of ALTO WG

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Med, Qin,

Thanks for triggering this discussion.

I will comment on Proposal #1, but not sure if part of my comments could be 
considered as related to Proposal #2.

I think that supporting ALTO operations is certainly needed. As long as we are 
having operational experience is evident that some additional work is needed. 
And also, some additional work is identified as convenient because of the new 
types of services that are being demanded if compared with the past. Let me 
please explain my arguments.

My first comment is on security. All aspects related to security required of 
additional work due to the criticality of the information being exposed. For 
instance, how to avoid the inference of sensible network information from the 
analysis of the values of the PID identifiers; or ways of isolating ALTO 
servers from potential attackers acting as clients e.g. by means of pub/sub 
schemes, to mention a couple of examples. Security is an important missing 
piece on ALTO specs, worthy to be developed. These situations are emerging now 
as consequence of deployment experience in real networks, so addressing real 
situations. There are some other areas of work related to deployments, but not 
to security, which are important as well, such as ALTO redundancy/protection, 
frequency of topology updates (i.e. freshness), etc, that can be relevant to 
consider, as well.

Second comment is on other ways of consuming ALTO information. For example, 
existing ALTO specs relay on PIDs for building network and cost maps. However, 
in operators' networks is extremely common to work with BGP communities as 
grouping of prefixes with a common purpose. Thus, it seems convenient to bring 
the idea of BGP communities into ALTO [1]. Note that the scope of a BGP 
community can differ from the scope of a PID (e.g., the BGP community 
representing a set of prefixes sharing a common characteristic other than the 
topological one). Note as well that the concept of BGP community is tightly 
related to the definition and application of policies. So, I guess you can 
perceive the potential of combining the information provided by ALTO (network + 
cost map+ further information such as performance metrics [2]) together with 
the network policies by means of BGP communities.

Third comment is on multi-domain. This is very sensible for operators. The vast 
majority of services today imply multi-domain setting. Just as an example, 
around 70 - 80% of traffic today in operators' network is coming from OTT 
services (video streaming, gaming, social networks, hybrid clouds, etc). This 
is intrinsically multidomain because content providers are different 
administrative domains, and in some cases there is the need of traversing 
intermediate domains for accessing contents. The role of multi-domain ALTO can 
be key for achieving a more efficient service delivery, end-to-end. And because 
this multi-domain nature, having standardize solutions is key for lowering 
integration time, costs and efforts. Defining common syntax and semantics of 
the interchanged information across domains is fundamental [3].

Fourth is on additional operational situations where ALTO can assist on 
simplifying the operation and improving the overall target of automation in 
service provider networks. Just as a couple of examples. Let's consider for 
instance the complexities generated in terms of keeping up-to-date network and 
cost maps for pools of prefixes being dynamically allocated in different parts 
of the network. In some cases, this is favored by the control-user plane 
separation (CUPS) approach, in some other cases because of the allocation of 
pools for CGNAT, or for APNs in the mobile network, etc. All of this dynamicity 
is difficult to track and keep updated, so ALTO can become an essential piece 
for an up-to-date view and operation of this complexity. Another example is 
represented by the proposition from the Fujitsu colleagues in ALTO in respect 
the consideration of geolocation information within the ALTO network and cost 
maps [4]. This is relevant not only for the trust-related scenarios as 
originally identified by Fujitsu, but also because it can be an enabler for 
other important operational cases such as the ones related to GPDR enforcement 
[5], which imposes obligations to operators.

Finally, having in mind the value of ALTO for operations, I think it is 
unavoidable to consider new capabilities originated by operational situations 
not present in our networks some years ago. Let me briefly refer to the 
exposure of additional information with topological relevance, for instance the 
one related to compute. As we all know, there is a new WG named CATS addressing 
part of the problem space related to the consideration of compute information. 
It is relevant to remark the "TS" part (i.e., traffic steering) since it 
implies that there are already in place some functions/applications where to 
steer the traffic, with the decision being 

Re: [alto] WGLC for draft-ietf-alto-new-transport (Ends 28/03/2023)

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Qin

The link provided redirects to 
https://datatracker.ietf.org/doc/html/draft-ietf-alto-oam-yang-06 instead of 
new transport draft. I assume the subject is correct and the WG LC is against 
new transport, correct? Just to be dure and reviewing the correct draft to 
answer this LC.

Thanks

Luis

De: alto  En nombre de Qin Wu
Enviado el: martes, 14 de marzo de 2023 2:06
Para: IETF ALTO 
CC: ALTO Working Group 
Asunto: [alto] WGLC for draft-ietf-alto-new-transport (Ends 28/03/2023)


Hi, All

This message starts 2 weeks WGLC for 
https://datatracker.ietf.org/doc/html/draft-ietf-alto-new-transport-07.
 The call ends: 28/03/2023.



Please review and indicate your support or objection to proceed with the 
publication of this document.



Thank you.



Cheers,

Med & Qin




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 confidential and privileged 
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

[alto] RV: New Version Notification for draft-contreras-tvr-alto-exposure-00.txt

[LUIS MIGUEL CONTRERAS MURILLO]

Dear all,

 I have submitted the draft below to the recently formed TVR working group. The 
aim of the draft is to explore the suitability of the ALTO cost calendar to 
expose time-variant routing information, as scoped in TVR. I suggest in the 
draft some areas of potential additional work required on ALTO.

I have asked for a slot in TVR to present the draft. I will do the same for 
ALTO meeting in Yokohama, but since there is less time in ALTO meeting that in 
TVR meeting, I think it can be skipped in ALTO in case there is no sufficient 
time for the other topics to cover.

Any comment / feedback on this is more than welcome. I hope this draft could 
open some interaction / collaboration among both WGs.

Best regards

Luis

-Mensaje original-
De: internet-dra...@ietf.org 
Enviado el: jueves, 2 de marzo de 2023 13:07
Para: LUIS MIGUEL CONTRERAS MURILLO 
; LUIS MIGUEL CONTRERAS MURILLO 

Asunto: New Version Notification for draft-contreras-tvr-alto-exposure-00.txt


A new version of I-D, draft-contreras-tvr-alto-exposure-00.txt
has been successfully submitted by Luis M. Contreras and posted to the IETF 
repository.

Name:   draft-contreras-tvr-alto-exposure
Revision:   00
Title:  Using ALTO for exposing Time-Variant Routing information
Document date:  2023-03-02
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/archive/id/draft-contreras-tvr-alto-exposure-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-contreras-tvr-alto-exposure/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-contreras-tvr-alto-exposure


Abstract:
   Network operations can require time-based, scheduled changes in
   nodes, links, adjacencies, etc.  All those changes can alter the
   connectivity in the network in a predictable manner, which is known
   as Time-Variant Routing (TVR).  Existing IETF solutions like ALTO can
   assist on the exposure of such predicted changes to both internal and
   external applications then anticipating the occurence of routing
   changes.  This document describes how ALTO helps in that purpose.




The IETF Secretariat





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 confidential and privileged 
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

Re: [alto] [Can] Clean copy CAN charter updated

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all,

(adding ALTO mailing list for this comment)

My apologies since I couldn't go through this during the weekend.

One comment from my side. Since ALTO is explicitly mentioned in the charter, I 
think it would be fair to differentiate this work wrt ALTO work in relation 
with network and compute information (due to the fact that there are some 
individual drafts in ALTO dealing from long with the joint exposure of network 
and compute information).

As mentioned in the proposed charter, CAN solution can take the decision on 
"... integrate both network and compute conditions in the optimization function 
...", while ALTO could be one of the solutions that precisely expose the 
combined network and compute conditions. So, CAN could act on top of ALTO's 
information.

I think they are not exclusive, but could be complementary in the mission of 
taking into consideration network and compute information (apart from other 
differences that is not worthy to detail for the purpose of chartering CAN).

I would simply add the sentence that "Exposure of network and compute 
conditions to applications is not in the scope of CAN" in this way:

OLD

The IETF has done past work on exposing network conditions to endpoints 
(notably ALTO) and load balancing/service selection at layers 4 and 7 (for 
example, related to the selection of SIP servers). Specific characteristics 
that may distinguish CAN from other work include the desire to integrate both 
network and compute conditions in the optimization function, and the desire to 
operate that function on nodes within the service provider's network, logically 
separated from service operation. As part of its work, the CAN WG will seek 
advice and expertise from the ART and TSV areas.

NEW
The IETF has done past work on exposing network conditions to endpoints 
(notably ALTO) and load balancing/service selection at layers 4 and 7 (for 
example, related to the selection of SIP servers). Specific characteristics 
that may distinguish CAN from other work include the desire to integrate both 
network and compute conditions in the optimization function, and the desire to 
operate that function on nodes within the service provider's network, logically 
separated from service operation. Exposure of network and compute conditions to 
applications is not in the scope of CAN. As part of its work, the CAN WG will 
seek advice and expertise from the ART and TSV areas.

Best regards, and apologies for this late comment.

Luis


De: Can  En nombre de Peng Liu
Enviado el: lunes, 13 de febrero de 2023 5:06
Para: adrian ; jgs 
CC: can ; Cheng Li ; Joel M. 
Halpern 
Asunto: Re: [Can] Clean copy CAN charter updated

Thanks. This version also looks good to me. Hope to see the progress in the 
IESG meeting.

Regards,
Peng

liupeng...@chinamobile.com

From: Cheng Li
Date: 2023-02-13 11:38
To: Joel Halpern; 
adr...@olddog.co.uk; 
j...@juniper.net
CC: c...@ietf.org
Subject: Re: [Can] Clean copy CAN charter updated
The updated Charter looks good enough to me as well. It provides a good 
baseline for discussion in IESG review.

BR,
Cheng



-Original Message-
From: Can [mailto:can-boun...@ietf.org] On Behalf Of Joel Halpern
Sent: Monday, February 13, 2023 4:58 AM
To: adr...@olddog.co.uk; 
j...@juniper.net
Cc: c...@ietf.org
Subject: Re: [Can] Clean copy CAN charter updated

Just to close the loop, the charter (still below) that Adrian distributed today 
looks good enough to me.

Yours,

Joel

On 2/12/2023 3:07 PM, Adrian Farrel wrote:
> Hi,
>
> Per the planned schedule, here is a -00-03.txt revision for you to
> post. The changes are as noted in the previous mail to the CAN list.
>
> I believe that the delta in this revision:
> - captures comments and discussions on the list
> - includes no change of substance from the previous
> - tightens (and simplifies) some of the terminology
> - fixes my breakage of your bullets
>
> Good luck on Thursday. Do you *want* anyone from the community to show
> on the telechat? (Obviously, everyone is welcome to be there.)
>
> Cheers,
> Adrian
>
> ===
>
> Computing-Aware Networking (can)
>
> Many service architectures create multiple service instances. These
> instances are often geographically distributed to multiple sites, and
> a single site may support multiple instances of a service. The
> services are provided on computing platforms and are generically
> referred to as "compute services". The CAN (Computing-Aware
> Networking) working group (WG) is chartered to consider the problem of
> how the network edge can steer traffic between clients of a service
> and sites offering the service.
>
> Since, for some services (for example, VR/AR, intelligent
> transportation), 

Re: [alto] Open discussion on providing resource-level access control in ALTO O

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Qin,

It is not yet clear to me if the access control should have the granularity of 
resource-id or resource-type (there could be different resources of the same 
type being consumed by the client, in principle, so N:1 relationship).

The second question I made about the resource type is orthogonal to the access 
control topic, but probably interesting to discuss as well, maybe as a separate 
thread.

Bets regards

Luis

De: Qin Wu 
Enviado el: martes, 20 de diciembre de 2022 10:26
Para: LUIS MIGUEL CONTRERAS MURILLO 
; Jensen Zhang 
; IETF ALTO 
CC: draft-ietf-alto-oam-y...@ietf.org
Asunto: RE: [alto] Open discussion on providing resource-level access control 
in ALTO O

Jensen, Luis and all:
I quote access control related requirements in RFC7285:
“
   An ALTO server requires at least the following logical inputs:
   o  Security policies mapping potential clients to the information
  that they have privilege to access.

The ALTO information (e.g., network maps and cost maps) being served by
   each ALTO server, as well as security policies (HTTP authentication,
   TLS client and server authentication, TLS encryption parameters)
   intended to serve the same information should be monitored for
   consistency.
“
We need to make sure our designed solution meet the basic requirements in 
RFC7285.

发件人: alto [mailto:alto-boun...@ietf.org] 代表 LUIS MIGUEL CONTRERAS MURILLO
发送时间: 2022年12月18日 5:36
收件人: Jensen Zhang 
mailto:jingxuan.n.zh...@gmail.com>>; IETF ALTO 
mailto:alto@ietf.org>>
抄送: draft-ietf-alto-oam-y...@ietf.org<mailto:draft-ietf-alto-oam-y...@ietf.org>
主题: Re: [alto] Open discussion on providing resource-level access control in 
ALTO O

HI Jensen, all,

Regarding the access to information resources a couple of questions come to my 
mind.

·   What would be the roles you consider for accessing the info? In your 
proposed piece of model the role is assigned by resource-id, but maybe it could 
make sense to apply that also (or alternatively) per resource-type
·   Related to resource-type. The model defined three types so far: 
network-map, cost-map and property-map. I wonder if a kind of registry should 
be defined for that allowing a more generic definition of the resource types 
thinking on future extensions of ALTO where new types could be defined.

What do you think?

Best regards

Luis

De: alto mailto:alto-boun...@ietf.org>> En nombre de 
Jensen Zhang
Enviado el: martes, 13 de diciembre de 2022 11:16
Para: IETF ALTO mailto:alto@ietf.org>>
CC: draft-ietf-alto-oam-y...@ietf.org<mailto:draft-ietf-alto-oam-y...@ietf.org>
Asunto: [alto] Open discussion on providing resource-level access control in 
ALTO O

Hi ALTOers,

From the discussion about the ALTO O draft last week, we find there is 
another open issue that we should solve before we request YANG doctor reviews:

According to Section 16.2.4 of RFC7285 and Requirement R5-3 of the ALTO O 
draft, the data model should support configuration for access control at the 
information resource level. In other words, the data model should configure:

1. How an ALTO server identifies an ALTO client?
2. Which ALTO clients can access a given information resource?

To realize them, we consider two design options:

---

Option 1: authentication and authorization based approach

- To realize the first one, conceptually, we should provide data model to 
configure authentication and authorization for each client. It can be simply 
based on username and password, or delegated to other more complex 
authentication systems like openID and LDAP.

- To realize the second one, a simple approach is to use a role-based solution. 
Every authenticated client can be assigned to multiple roles. And each 
information resource can configure to be accessible by given roles.

The YANG module can be like the following:

+--rw alto!
   +--rw alto-server
  ...
  +--rw auth-client* [username]
  |  +--rw username string
  |  +--rw (auth-config)
  |  +--:(basic-auth)
  |  |  +--rw username string
  |  |  +--rw password string
  |  ...
  |  +--rw role* role-name
  +--rw resource* [resource-id]
 ...
 +-- rw accepted-role* role-name
 ...

The choice auth-config can be augmented for different authentication protocols.

We can reference or even reuse the openconfig-aaa data mode [1].

[1] 
https://github.com/openconfig/public/blob/master/release/models/system/openconfig-aaa.yang

---

Option 2: ACL based approach

This approach only requires the server to configure an ACL. We can reuse the 
YANG data model defined by RFC8519 [2]. It only filters the traffic by the 
packet attributes, not the application-level authentication. Compared with 
option 1, it may lose some fine-grained control. But for some simple use cases 
like CDN or cloud networks, it may be good enough.

[2]: https://datatracker.ietf.org/doc/html/rfc8519

---

We are looking forward to seeing commen

Re: [alto] Open discussion on providing resource-level access control in ALTO O

[LUIS MIGUEL CONTRERAS MURILLO]

HI Jensen, all,

Regarding the access to information resources a couple of questions come to my 
mind.


  *   What would be the roles you consider for accessing the info? In your 
proposed piece of model the role is assigned by resource-id, but maybe it could 
make sense to apply that also (or alternatively) per resource-type
  *   Related to resource-type. The model defined three types so far: 
network-map, cost-map and property-map. I wonder if a kind of registry should 
be defined for that allowing a more generic definition of the resource types 
thinking on future extensions of ALTO where new types could be defined.

What do you think?

Best regards

Luis

De: alto  En nombre de Jensen Zhang
Enviado el: martes, 13 de diciembre de 2022 11:16
Para: IETF ALTO 
CC: draft-ietf-alto-oam-y...@ietf.org
Asunto: [alto] Open discussion on providing resource-level access control in 
ALTO O

Hi ALTOers,

From the discussion about the ALTO O draft last week, we find there is 
another open issue that we should solve before we request YANG doctor reviews:

According to Section 16.2.4 of RFC7285 and Requirement R5-3 of the ALTO O 
draft, the data model should support configuration for access control at the 
information resource level. In other words, the data model should configure:

1. How an ALTO server identifies an ALTO client?
2. Which ALTO clients can access a given information resource?

To realize them, we consider two design options:

---

Option 1: authentication and authorization based approach

- To realize the first one, conceptually, we should provide data model to 
configure authentication and authorization for each client. It can be simply 
based on username and password, or delegated to other more complex 
authentication systems like openID and LDAP.

- To realize the second one, a simple approach is to use a role-based solution. 
Every authenticated client can be assigned to multiple roles. And each 
information resource can configure to be accessible by given roles.

The YANG module can be like the following:

+--rw alto!
   +--rw alto-server
  ...
  +--rw auth-client* [username]
  |  +--rw username string
  |  +--rw (auth-config)
  |  +--:(basic-auth)
  |  |  +--rw username string
  |  |  +--rw password string
  |  ...
  |  +--rw role* role-name
  +--rw resource* [resource-id]
 ...
 +-- rw accepted-role* role-name
 ...

The choice auth-config can be augmented for different authentication protocols.

We can reference or even reuse the openconfig-aaa data mode [1].

[1] 
https://github.com/openconfig/public/blob/master/release/models/system/openconfig-aaa.yang

---

Option 2: ACL based approach

This approach only requires the server to configure an ACL. We can reuse the 
YANG data model defined by RFC8519 [2]. It only filters the traffic by the 
packet attributes, not the application-level authentication. Compared with 
option 1, it may lose some fine-grained control. But for some simple use cases 
like CDN or cloud networks, it may be good enough.

[2]: https://datatracker.ietf.org/doc/html/rfc8519

---

We are looking forward to seeing comments or suggestions on this open issue 
from the WG.

Best regards,
Jensen on behalf of coauthers of ALTO O draft



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 confidential and privileged 
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

[alto] RV: IETF ALTO Meeting on Dec 13th [Fujitsu: "Trust-Enhanced Networking"]

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all,

Forwarding this to the WG mailing list since it is of interest for the working 
group.

Best regards

Luis

De: ayoub.mess...@fujitsu.com 
Enviado el: lunes, 12 de diciembre de 2022 10:52
Para: 'roland.sch...@telekom.de' ; 
j...@qti.qualcomm.com; bill...@huawei.com; jacob.dunef...@yale.edu; 
jingxuan.n.zh...@gmail.com; kai...@scu.edu.cn; lauren.delwi...@yale.edu; LUIS 
MIGUEL CONTRERAS MURILLO ; 
mahdi.soleim...@yale.edu; sabine.randriam...@nokia-bell-labs.com; 
xzy...@gmail.com; y...@cs.yale.edu
CC: Junichi Suga (Fujitsu) ; Motoyoshi Sekiya 
(Fujitsu) ; andikan.ot...@fujitsu.com; Masatomo 
Gotou (Fujitsu) ; Kenji Hikichi (Fujitsu) 
; Koki Inoue (Fujitsu) ; 
Keiichi Nakatsugawa (Fujitsu) 
Asunto: RE: IETF ALTO Meeting on Dec 13th [Fujitsu: "Trust-Enhanced Networking"]

Dear ALTO team,

I am glad to inform you that Fujitsu published the white paper on the concept 
of "Trust-Enhanced Networking", which enhances trust in cyberspace with 
physical attributes of the real world.
https://www.fujitsu.com/global/about/research/article/202212-trust-enhanced-networking.html

This concept is a key focus as part of our current research topic that we would 
like to bring to the IETF community and to the ALTO work group.
Please feel free to prepare any questions or feedback about this concept for 
our meeting tomorrow.

Kind regards,
Ayoub


Ayoub MESSOUS, Phd.
Principal Researcher in Network Security & Trust.
Data & Security Research Group (DSR).
Fujitsu Research of Europe (FRE)
Web: https://www.fujitsu.com/uk/about/local/corporate/subsidiaries/fle/





From: Sekiya, Motoyoshi/関屋 元義 
mailto:sekiya.motoy...@fujitsu.com>>
Sent: 02 December 2022 23:35
To: 'roland.sch...@telekom.de' 
mailto:roland.sch...@telekom.de>>; 
j...@qti.qualcomm.com<mailto:j...@qti.qualcomm.com>
Cc: Suga, Junichi/須加 純一 
mailto:suga.juni...@fujitsu.com>>; Otung, Andikan 
mailto:andikan.ot...@fujitsu.com>>; Messous, Ayoub 
mailto:ayoub.mess...@fujitsu.com>>; 
bill...@huawei.com<mailto:bill...@huawei.com>; 
jacob.dunef...@yale.edu<mailto:jacob.dunef...@yale.edu>; 
jingxuan.n.zh...@gmail.com<mailto:jingxuan.n.zh...@gmail.com>; 
kai...@scu.edu.cn<mailto:kai...@scu.edu.cn>; 
lauren.delwi...@yale.edu<mailto:lauren.delwi...@yale.edu>; 
luismiguel.contrerasmuri...@telefonica.com<mailto:luismiguel.contrerasmuri...@telefonica.com>;
 mahdi.soleim...@yale.edu<mailto:mahdi.soleim...@yale.edu>; 
sabine.randriam...@nokia-bell-labs.com<mailto:sabine.randriam...@nokia-bell-labs.com>;
 xzy...@gmail.com<mailto:xzy...@gmail.com>; 
y...@cs.yale.edu<mailto:y...@cs.yale.edu>; Sekiya, Motoyoshi/関屋 元義 
mailto:sekiya.motoy...@fujitsu.com>>
Subject: RE: IETF ALT Meeting on Dec 6th

Dear Jordi , Roland and ALTO team

Thank you very much for reply.  We will do at Dec 13th.  Im very looking 
forward to discuss with the TEAM

PS.  Thank you very much.  The match was 4AM in Japan but lack of sleep has 
gone away
 Honestly I didn’t expect the result…. Thank you.

Sekiya

From: roland.sch...@telekom.de<mailto:roland.sch...@telekom.de> 
mailto:roland.sch...@telekom.de>>
Sent: Friday, December 2, 2022 10:19 PM
To: j...@qti.qualcomm.com<mailto:j...@qti.qualcomm.com>; Sekiya, Motoyoshi/関屋 
元義 mailto:sekiya.motoy...@fujitsu.com>>
Cc: Suga, Junichi/須加 純一 
mailto:suga.juni...@fujitsu.com>>; Otung, Andikan 
mailto:andikan.ot...@fujitsu.com>>; Messous, Ayoub 
mailto:ayoub.mess...@fujitsu.com>>; 
bill...@huawei.com<mailto:bill...@huawei.com>; 
jacob.dunef...@yale.edu<mailto:jacob.dunef...@yale.edu>; 
jingxuan.n.zh...@gmail.com<mailto:jingxuan.n.zh...@gmail.com>; 
kai...@scu.edu.cn<mailto:kai...@scu.edu.cn>; 
lauren.delwi...@yale.edu<mailto:lauren.delwi...@yale.edu>; 
luismiguel.contrerasmuri...@telefonica.com<mailto:luismiguel.contrerasmuri...@telefonica.com>;
 mahdi.soleim...@yale.edu<mailto:mahdi.soleim...@yale.edu>; 
sabine.randriam...@nokia-bell-labs.com<mailto:sabine.randriam...@nokia-bell-labs.com>;
 xzy...@gmail.com<mailto:xzy...@gmail.com>; 
y...@cs.yale.edu<mailto:y...@cs.yale.edu>
Subject: AW: IETF ALT Meeting on Dec 6th

Hi,

13th also works better for me.

Congratulations to you both and good luck for the rest of the championship.

Best Regards

Roland


Von: Jordi Ros Giralt mailto:j...@qti.qualcomm.com>>
Gesendet: Freitag, 2. Dezember 2022 13:13
An: Motoyoshi Sekiya (Fujitsu) 
mailto:sekiya.motoy...@fujitsu.com>>; 'Y.R. Yang' 
mailto:y...@cs.yale.edu>>
Cc: Junichi Suga (Fujitsu) 
mailto:suga.juni...@fujitsu.com>>; Schott, Roland 
mailto:roland.sch...@telekom.de>>; 
andikan.ot...@fujitsu.com<mailto:andikan.ot...@fujitsu.com>; 
ayoub.mess...@fujitsu.com<mailto:ayoub.mess...@fujitsu.com>; 
'bill...@huawei.com' mailto:bill...@huawei.com>>; 
'jacob.dunef...@yale.edu' 
mailto:jacob.dunef...@yale.edu&

[alto] Presentation at MOPS session of the progress of ALTO integration in Telefonica for CDN case

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all,

This is just to comment that tomorrow Monday I will present at MOPS wg meeting 
the status of the integration of ALTO in Telefonica for exposing network 
information to Telefonica CDN. The status will be also reported during ALTO 
session on Friday.

Best regards

Luis

--
Luis M. Contreras

Transport & IP Networks
Systems and Network Global Direction
Telefónica I+D / CTIO unit / Telefónica

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

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 confidential and privileged 
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

Re: [alto] Presenting ALTO-related work at MOPS WG on Friday

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Richard, all,

Certainly it was very interesting to present at MOPS WG the advances on ALTO 
integration in Telefonica and to get questions and feedback from their side.

Apart from the presentation pointer shared by Med, the group can take a look at 
the minutes [1] and the video recording of the ALTO presentation in MOPS 
session [2].

As summary of the questions, they were focused on the operational aspects of 
this integration. Let me summarize them.

R. K. Rajeev, from picoNETS (a CDN provider) asked about the handling of both 
the network and cost maps in order to provide the pursued network awareness to 
the CDN overlay, helping me to clarify that a further processing is needed by 
the CDN logic in order to filter the PIDs of interest. That is, the CDN logic 
takes into account the ones that relate CDN streamers with end-user prefixes 
per central office, not requiring the consideration of e.g. the relationship 
among PIDs of end-users only. Another question from Rajeev serve to clarify 
that the PIDs related to end-users group all the IP prefix ranges declared in 
each central office.

Éric Vyncke, from Cisco, asked about the expected frequency of the information 
retrieval. This helped me to clarify the fact that a weekly or even daily 
retrieval could be sufficient. It should be noted that in the present mode of 
operation the manual topology update is every 6 months, so the advantage of 
leveraging on ALTO is clear in the pathway towards general automation of an 
efficient delivery of contents with up-to-date information of the underlying 
network.

Finally, Sanjay Mishra, from Verizon, asked if the ALTO capabilities are 
considered to be offered to third parties (i.e., external consumers of network 
information such as topology, etc). The answer is yes, so ALTO can be queried 
by such 3rd parties. Finally Sanjay asked about how to handle the selection of 
streamers, and this served me to clarify that the logic of the CDN takes into 
consideration more information such as the availability of the requested 
content per streamer, its load status, etc.

My objective is to provide further details of this integration for IETF 115 
since we expect to complete the deployment in the production network of one of 
the Telefonica’s operation at that time. Operational insights of this 
integration can be of interest, in my view (aspects such as scalability, etc).

I think we have a good momentum to strength the collaboration with MOPS, as 
well.

Thanks for the interest,

Best regards

Luis

[1] https://notes.ietf.org/notes-ietf-114-mops#

[2] https://youtu.be/64MCGa242BM?t=4736


De: Y. Richard Yang 
Enviado el: viernes, 29 de julio de 2022 17:56
Para: mohamed.boucad...@orange.com
CC: LUIS MIGUEL CONTRERAS MURILLO ; 
alto@ietf.org
Asunto: Re: [alto] Presenting ALTO-related work at MOPS WG on Friday

I was at the presentations by Luis. Excellent presentation and great Q! We 
should share the questions and answers back to this mailing list.

Richard

On Fri, Jul 29, 2022 at 11:52 AM 
mailto:mohamed.boucad...@orange.com>> wrote:
Hi all,

The slides that are presented by Luis can be seen at: 
https://datatracker.ietf.org/meeting/114/materials/slides-114-mops-exposure-of-telefonica-network-topology-through-alto-for-integration-with-telefonica-cdn/

Cheers,
Med

De : alto mailto:alto-boun...@ietf.org>> De la part de 
LUIS MIGUEL CONTRERAS MURILLO
Envoyé : lundi 25 juillet 2022 23:32
À : 'alto@ietf.org<mailto:alto@ietf.org>' mailto:alto@ietf.org>>
Objet : [alto] Presenting ALTO-related work at MOPS WG on Friday

Dear ALTOers,

For those interested, next Friday at MOPS WG I will have the opportunity to 
present the work in Telefonica for the integration of ALTO as a way of exposing 
topology information to Telefonica CDN.

The session is entitled “Exposure of Telefonica network topology through ALTO 
for integration with Telefonica CDN” 
(https://datatracker.ietf.org/meeting/114/materials/agenda-114-mops-02.txt).

Best regards

Luis

__
Luis M. Contreras

Transport & IP Networks
Systems and Network Global Direction
Telefónica I+D / CTIO unit / Telefónica

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

Mobile: +34 680 947 650
luismiguel.contrerasmuri...@telefonica.com<mailto: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 confid

[alto] Presenting ALTO-related work at MOPS WG on Friday

[LUIS MIGUEL CONTRERAS MURILLO]

Dear ALTOers,

For those interested, next Friday at MOPS WG I will have the opportunity to 
present the work in Telefonica for the integration of ALTO as a way of exposing 
topology information to Telefonica CDN.

The session is entitled "Exposure of Telefonica network topology through ALTO 
for integration with Telefonica CDN" 
(https://datatracker.ietf.org/meeting/114/materials/agenda-114-mops-02.txt).

Best regards

Luis

__
Luis M. Contreras

Transport & IP Networks
Systems and Network Global Direction
Telefónica I+D / CTIO unit / Telefónica

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

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 confidential and privileged 
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

Re: [alto] Some comments about draft-lcsr-alto-service-functions-01

[LUIS MIGUEL CONTRERAS MURILLO]

Thanks so much Med for your detailed review. We will go through your comments 
in the next days.

Thanks again

Luis

De: alto  En nombre de mohamed.boucad...@orange.com
Enviado el: martes, 19 de julio de 2022 15:14
Para: draft-lcsr-alto-service-functi...@ietf.org
CC: alto@ietf.org
Asunto: [alto] Some comments about draft-lcsr-alto-service-functions-01

Hi Luis, Sabine, and Xufeng,

Thank you for editing this draft.

FWIW, you may find some comments at:


  *   pdf: 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-lcsr-alto-service-functions-01-rev%20Med.pdf
  *   doc: 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-lcsr-alto-service-functions-01-rev%20Med.doc

Cheers,
Med

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.



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 confidential and privileged 
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

Re: [alto] Review of draft-lcsr-alto-service-functions

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Qin,

Thanks for the comments and questions.

Please, see in-line

Best regards

Luis

De: Qin Wu 
Enviado el: miércoles, 13 de julio de 2022 5:57
Para: LUIS MIGUEL CONTRERAS MURILLO 
CC: alto@ietf.org; draft-lcsr-alto-service-functi...@ietf.org
Asunto: Review of draft-lcsr-alto-service-functions

Hi, Luis:
Thank for your proposed new draft on service function handling 
(https://datatracker.ietf.org/doc/draft-lcsr-alto-service-functions/), I 
believe it is related to service function invocation use case. Thanks for that.
ALTO Path vector seems a good basis for your requested protocol extension.
One thing I am not very clear is
1.who will be the client to consume ALTO information combining network topo 
info and service function information?
[Luis>>] We can consider two kind of use cases: (1) the need for determining 
path characteristics to an instance of a SF, or (2) the same but for a service 
chain.
In the case of (1), the client of ALTO information can be the entity in charge 
of determining the steering towards a function, then deciding between multiple 
instances what is the optimal one according to some metrics (less hops, a 
certain delay or BW -according to ALTO performance metrics-, etc). This can be 
done for a single SF instance, or recursively, to identify the optimal 
instances for composing a service chain.
In the case of (2) the client could essentially determine the more convenient 
chain (assuming it is already formed)
Clients of this could be either the SFC Classifier [RFC7665] or the SFC 
Controller [draft-ietf-sfc-control-plane-08], the controller/PCE that could set 
up a chain based on SR / SRv6 [draft-ietf-spring-sr-service-programming], the 
MANO and/or WIM in ETSI NFV architecture for interconnecting deployed VNFs 
[ETSI GR NFV-SOL 017], the 3GPP management system e.g. for selecting among 
distributed UPFs, etc.

Should it be cross domain service orchestration system, or ingress node or 
headend?
[Luis>>] What I have in mind is the client being an orchestrator or alike, 
either internal or external to IETF context. The consideration of ingress node 
is interesting to take, thanks for pointing this out. Food for thought.
2.How does such client consume these information?
[Luis>>] In my view, the consumption of the information will be similar as ALTO 
clients do today. That is, taking ALTO outcome as an informed raking of 
alternatives that can be further processed together with other information on 
the hands of the client, to perform the optimal selection from the client's 
perspective. Does it make sense?

-Qin



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 confidential and privileged 
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

Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-architecture-03

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all

Same here, I also support to progress with this document.

Best regards

Luis

De: OPSAWG  En nombre de Yangfan(Fan, IP Standards)
Enviado el: jueves, 23 de junio de 2022 13:07
Para: Tianran Zhou ; opsawg@ietf.org
Asunto: Re: [OPSAWG] WGLC for 
draft-ietf-opsawg-service-assurance-architecture-03

Hi OPSAWG,

I support the progress of this document.
Thank you!

Best,
Fan


From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Wednesday, June 8, 2022 6:00 PM
To: opsawg@ietf.org
Subject: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-architecture-03

Hi WG,

This mail we start a two weeks working group last call for 
draft-ietf-opsawg-service-assurance-architecture-03.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-architecture/
Please send over your comments before June 22.
Please also indicate if you think this document is ready to progress.

Cheers,
Tianran, on behalf of chairs



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 confidential and privileged 
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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all

I also support the progression of this document.

Best regards

Luis

De: OPSAWG  En nombre de Wubo (lana)
Enviado el: viernes, 24 de junio de 2022 12:53
Para: Tianran Zhou ; opsawg@ietf.org
Asunto: Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

Hi all,

I have read this draft and I think this draft is ready to progress. This YANG 
model is an important part of SAIN architecture.

Thanks,
Bo

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Wednesday, June 8, 2022 6:04 PM
To: opsawg@ietf.org
Subject: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05

Hi WG,

This mail we start a two weeks working group last call for 
draft-ietf-opsawg-service-assurance-yang-05.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/

Please send over your comments before June 22.
Please also indicate if you think this document is ready to progress.

Cheers,
Tianran, on behalf of chairs




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 confidential and privileged 
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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [alto] Fw: Re: [Dyncast] CAN BoF issues #1 #5 #6

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Peng,

In my view, ALTO can be seen as an alternative (maybe complementary) way of 
addressing the problem space of computing-aware networking. The CAN proposition 
at RTG tries to solve the problem from on-path forwarding-based decisions, 
while ALTO try to solve the problem by exposing information that can be 
consumed by applications/services before traffic delivery. So in that respect, 
even targeting a common problem, both provide different approaches, then 
imposing different needs but also taking different assumptions on how 
applications and networks interact.

For more detailed comments, please see my answers in-line

Bets regards

Luis

De: alto  En nombre de liupeng...@chinamobile.com
Enviado el: miércoles, 18 de mayo de 2022 15:46
Para: alto 
CC: dyncast 
Asunto: [alto] Fw: Re: [Dyncast] CAN BoF issues #1 #5 #6

Hi ALTO WG,

There was a Computing-Aware Networking(CAN) BoF of RTG area in IETF 113, which 
is to steer the traffic among multiple edge sites considering both network and 
computing resource statues. The progress was also presented briefly in ALTO WG 
meeting.

In the BoF, some people cared about the relationship between CAN and ALTO. We 
collected this issue and got the response from the proponents, also would like 
to post the clarification to see if there are more comments from the WG. Thanks!

#5 What is the relation between CAN and ALTO? (issue 
#5)

ALTO architecture has a central ALTO server pulling network status periodically 
to help managing deployment of the application and computing resource. But it 
is difficult for ALTO server to promptly assist many ingress nodes in choosing 
the optimal path based on the dynamic traffic conditions and computing 
resources at multiple locations because: 1) single point of bottleneck for all 
ingress routers to query application status;
[Luis>>] I think that this is rather a matter of scalable design, than an 
actual limitation in the sense that different instances of ALTO server could be 
put if actually needed.
2) time taken for ingress routers to get the responses from the ALTO server 
upon flows arrival;
[Luis>>] Again I don’t see this as an actual issue in the sense that 
applications could interrogate ALTO server before deciding what is the best 
path to follow. We can expect very quick interaction with ALTO to assist on the 
decision, that will be later on applied to all the packets in the flow (until 
further optimization could be required by the application). ALTO will have 
timely information from the network, so always offering fresh info for 
assisting applications.
3) ALTO server may not know the instantaneous congestion status of the network, 
all link bandwidths, all information about the actual routing and whether the 
candidate endpoint itself is overloaded according to RFC7971
[Luis>>] In this respect ALTO can integrate performance metric information as 
described in draft-ietf-alto-performance-metrics
CAN is to identify various measurements for service instances including the 
hosting environment, get them normalized together with network metrics for 
ingress nodes to choose the service instances.

Regards,
Peng

liupeng...@chinamobile.com

From: Linda Dunbar
Date: 2022-05-18 05:46
To: liupeng...@chinamobile.com; 
dyncast
CC: rtgwg
Subject: Re: [Dyncast] CAN BoF issues #1 #5 #6
Peng,

The resolution for Issue 2 “Relation to ALTO” can add more on why ALTO “can’t 
really help to the service request”. How about the following?

Relation to ALTO (issue 
#5)

ALTO architecture has a central ALTO server pulling network status periodically 
to help managing deployment of the application and computing resource. But it 
is difficult for ALTO server to promptly assist many ingress nodes in choosing 
the optimal path based on the dynamic traffic conditions and computing 
resources at multiple locations because: 1) single point of bottleneck for all 
ingress routers to query application status; 2) time taken for ingress routers 
to get the responses from the ALTO server upon flows arrival; 3) ALTO server 
may not know the instantaneous congestion status of the network, all link 
bandwidths, all information about the actual routing and whether the candidate 
endpoint itself is overloaded according to RFC7971
CAN is to identify various measurements for service instances including 

Re: [alto] Call for Adoption: draft-bw-alto-cost-mode-01

[LUIS MIGUEL CONTRERAS MURILLO]

I support the adoption, as well

Thanks

Luis

-Mensaje original-
De: alto  En nombre de Randriamasy, Sabine (Nokia - 
FR/Paris-Saclay)
Enviado el: lunes, 7 de marzo de 2022 15:10
Para: Qin Wu ; 
mohamed.boucad...@orange.com; kai...@scu.edu.cn; alto@ietf.org; 
alto-cha...@ietf.org
Asunto: Re: [alto] Call for Adoption: draft-bw-alto-cost-mode-01

+1
And agree on the information to be added on the IANA registry cost mode entries.
Best regards,
Sabine

>-Original Message-
>From: alto  On Behalf Of Qin Wu
>Sent: Monday, March 7, 2022 2:26 PM
>To: mohamed.boucad...@orange.com; kai...@scu.edu.cn; alto@ietf.org;
>alto-cha...@ietf.org
>Subject: Re: [alto] Call for Adoption: draft-bw-alto-cost-mode-01
>
>+1,
>For the record, I have no IPR related to this draft.
>
>-Qin
>-邮件原件-
>发件人: mohamed.boucad...@orange.com
>[mailto:mohamed.boucad...@orange.com]
>发送时间: 2022年3月7日 19:49
>收件人: kai...@scu.edu.cn; alto@ietf.org; alto-cha...@ietf.org
>主题: RE: [alto] Call for Adoption: draft-bw-alto-cost-mode-01
>
>Hi Kai,
>
>Thank you for taking care of the call.
>
>FWIW, I don't have any IPR related to this draft.
>
>Cheers,
>Med
>
>> -Message d'origine-
>> De : alto  De la part de kai...@scu.edu.cn
>> Envoyé : lundi 7 mars 2022 12:28 À : alto@ietf.org;
>> alto-cha...@ietf.org Objet : [alto] Call for Adoption:
>> draft-bw-alto-cost-mode-01
>>
>> Dear all,
>>
>> I have been appointed to run the Call for Adoption of draft-bw-alto-
>> cost-mode-01.
>>
>> Following up with what has been proposed and agreed during the IESG
>> review on draft-ietf-alto-path-vector [1], we are starting a call for
>> adoption of the ALTO cost mode [2] document as a charter deliverable.
>> It both helps push forward existing WG document and fits in the
>> protocol maintenance item in the current charter.
>>
>> The Call for Adoption will close on March 21 (2 weeks after the IETF
>> submission deadline). Please post to the mailing list if you support
>> or appose the adoption, or have any comments or suggestions.
>>
>> [1] https://mailarchive.ietf.org/arch/msg/alto/WWoyJyM0PioBWM_rADYT-
>> Z_I8t4/
>> [2] https://datatracker.ietf.org/doc/html/draft-bw-alto-cost-mode-01
>>
>> Thanks!
>>
>> Best,
>> Kai
>> ___
>> alto mailing list
>> alto@ietf.org
>> https://www.ietf.org/mailman/listinfo/alto
>
>_
>
>
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>exploites ou copies sans autorisation. Si vous avez recu ce message par
>erreur, veuillez le signaler a l'expediteur et le detruire ainsi que
>les pieces jointes. Les messages electroniques etant susceptibles
>d'alteration, Orange decline toute responsabilite si ce message a ete altere, 
>deforme ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged
>information that may be protected by law; they should not be
>distributed, used or copied without authorisation.
>If you have received this email in error, please notify the sender and
>delete this message and its attachments.
>As emails may be altered, Orange is not liable for messages that have
>been modified, changed or falsified.
>Thank you.
>
>___
>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



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 confidential and privileged 
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 

Re: [alto] Call for Adoption: draft-bw-alto-cost-mode-01

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all,

I agree with Dhruv on the fact that enabling private use could be useful. I’m 
thinking on the fact of positioning ALTO as IETF Network Exposure Function (as 
described in draft-contreras-alto-ietf-nef-00) where some private (non-standard 
or experimental) information could be exposed among parties for specific 
purposes.

Best regards

Luis

De: alto  En nombre de Dhruv Dhody
Enviado el: martes, 8 de marzo de 2022 8:09
Para: mohamed.boucad...@orange.com
CC: alto-cha...@ietf.org; Kai Gao ; alto 
Asunto: Re: [alto] Call for Adoption: draft-bw-alto-cost-mode-01

Hi Med,

On Tue, Mar 8, 2022 at 11:53 AM 
mailto:mohamed.boucad...@orange.com>> wrote:
Hi Dhruv,

Thank you for the comments.

We will be adding a “description” in the next iteration, however the details 
about the structure/etc should not be echoed in the table but be available in 
the pointer provided under “Specification”.


Dhruv: Maybe I was not clear. I meant to say the IANA sections in RFC 7285 
included a lot more text than what is there in this I-D. See 
https://datatracker.ietf.org/doc/html/rfc7285#section-14.2 and 
https://datatracker.ietf.org/doc/html/rfc7285#section-14.3. I was suggesting 
using a similar format and adding more text about this new registry as well.


I’m not sure a specific prefix for private use is needed, but I may be 
mistaken. When running experiments, the owners can just pick any value which 
does not conflict with a value in the registry + provide the semantic/behavior 
to ALTO nodes that are involved in the experiment.


Dhruv: Experiments sometimes leak into the wild and thus we discourage simply 
picking any value and opting for private use and experimental use values in the 
IANA registry. Further, consistency in the protocol extensions is a good thing 
to have, and thus using priv: makes sense to me! I was not in the room when RFC 
7285 was being developed. Maybe some of the OG participants from the WG could 
through some light on this as well :)

Thanks!
Dhruv


Cheers,
Med

De : Dhruv Dhody mailto:dhruv.i...@gmail.com>>
Envoyé : mardi 8 mars 2022 06:52
À : Kai Gao mailto:kai...@scu.edu.cn>>
Cc : alto mailto:alto@ietf.org>>; 
alto-cha...@ietf.org
Objet : Re: [alto] Call for Adoption: draft-bw-alto-cost-mode-01

Hi Kai,

Support adoption!

Should the IANA consideration section follow the format followed by RFC 7285 
which includes lot more details on the rationale, requested information, string 
format etc.

That also made me wonder if there is some benefit to also mark priv: for 
private use as done for some of the other ALTO registries.

Thanks!
Dhruv

On Mon, Mar 7, 2022 at 4:58 PM mailto:kai...@scu.edu.cn>> 
wrote:
Dear all,

I have been appointed to run the Call for Adoption of 
draft-bw-alto-cost-mode-01.

Following up with what has been proposed and agreed during the IESG review on 
draft-ietf-alto-path-vector [1], we are starting a call for adoption of the 
ALTO cost mode [2] document as a charter deliverable. It both helps push 
forward existing WG document and fits in the protocol maintenance item in the 
current charter.

The Call for Adoption will close on March 21 (2 weeks after the IETF submission 
deadline). Please post to the mailing list if you support or appose the 
adoption, or have any comments or suggestions.

[1] https://mailarchive.ietf.org/arch/msg/alto/WWoyJyM0PioBWM_rADYT-Z_I8t4/
[2] https://datatracker.ietf.org/doc/html/draft-bw-alto-cost-mode-01

Thanks!

Best,
Kai
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.



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 

Re: [alto] New chair!

[LUIS MIGUEL CONTRERAS MURILLO]

Congrats Med!

and thanks Jan for your work along these past years.

Best regards

Luis

De: alto  En nombre de Qin Wu
Enviado el: martes, 7 de diciembre de 2021 14:25
Para: Martin Duke ; IETF ALTO 
Asunto: Re: [alto] New chair!

Welcome Med! Wonderful to have you.
Thanks all the other volunteers, look forward to continue to work with you as a 
team.
And also express my thanks to Jan, in advance, for his service as ALTO chair.

-Qin
发件人: alto [mailto:alto-boun...@ietf.org] 代表 Martin Duke
发送时间: 2021年12月7日 1:57
收件人: IETF ALTO mailto:alto@ietf.org>>
主题: [alto] New chair!

Hello ALTO,

I'd like to welcome Mohamed Boucadair, of Orange, as the new ALTO chair. This 
frees Jan to step down at his convenience. When he chooses to do so, we'll 
thank him properly.

Mohamed has not been intimately involved with ALTO, but he will bring 
significant IETF experience and an operator's perspective to the role. Thanks 
for serving, Mohamed!

I'd also like to thank the other candidates. We were blessed with several 
volunteers who all would have done a fine job, and it was hard to pick from 
them.

Martin



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

Re: [alto] Meeting Info for Nov 2, 2021

[LUIS MIGUEL CONTRERAS MURILLO]

No worries, thanks

Luis

De: kai...@scu.edu.cn 
Enviado el: martes, 2 de noviembre de 2021 12:31
Para: LUIS MIGUEL CONTRERAS MURILLO 
CC: alto@ietf.org; alto-weekly-meet...@googlegroups.com
Asunto: Re: RE: [alto] Meeting Info for Nov 2, 2021


Hi Luis,



Yes, it should be 2:00 pm CET. Sorry for the confusion.



Best,

Kai



2021-11-02 16:21:25"LUIS MIGUEL CONTRERAS MURILLO" 
wrote:
Hi Kao,

Last weekend we had in Europe the time adjustment, so I guess that the new time 
for the meeting in Europe is 14:00 CET instead of 15:00 CET.

Please, can you confirm?

Best regards

Luis

De: alto mailto:alto-boun...@ietf.org>> En nombre de 
kai...@scu.edu.cn<mailto:kai...@scu.edu.cn>
Enviado el: lunes, 1 de noviembre de 2021 17:11
Para: alto@ietf.org<mailto:alto@ietf.org>; 
alto-weekly-meet...@googlegroups.com<mailto:alto-weekly-meet...@googlegroups.com>
Asunto: [alto] Meeting Info for Nov 2, 2021


Dear all,



This is a friendly reminder that we will have the ALTO weekly meeting at 9:00 
am US EST (3:00 pm CET and 9:00 pm Beijing Time) on Tuesday, November 2, 2021.



Agenda:

- Preparation for IETF 112



Bridge:

https://yale.zoom.us/my/yryang



If you want to put a new topic to the agenda, please feel free to let me know.



Best,

Kai



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



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

Re: [alto] Meeting Info for Nov 2, 2021

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Kao,

Last weekend we had in Europe the time adjustment, so I guess that the new time 
for the meeting in Europe is 14:00 CET instead of 15:00 CET.

Please, can you confirm?

Best regards

Luis

De: alto  En nombre de kai...@scu.edu.cn
Enviado el: lunes, 1 de noviembre de 2021 17:11
Para: alto@ietf.org; alto-weekly-meet...@googlegroups.com
Asunto: [alto] Meeting Info for Nov 2, 2021


Dear all,



This is a friendly reminder that we will have the ALTO weekly meeting at 9:00 
am US EST (3:00 pm CET and 9:00 pm Beijing Time) on Tuesday, November 2, 2021.



Agenda:

- Preparation for IETF 112



Bridge:

https://yale.zoom.us/my/yryang



If you want to put a new topic to the agenda, please feel free to let me know.



Best,

Kai



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

[alto] RV: New Version Notification for draft-contreras-alto-ietf-nef-00.txt

[LUIS MIGUEL CONTRERAS MURILLO]

Dear all,

As mentioned during our weekly calls, I created a first version of a draft 
positioning ALTO as IETF Network Exposure Function. Comments are more than 
welcome.

Thanks

Luis

-Mensaje original-
De: internet-dra...@ietf.org 
Enviado el: lunes, 25 de octubre de 2021 20:50
Para: LUIS MIGUEL CONTRERAS MURILLO 
; LUIS MIGUEL CONTRERAS MURILLO 

Asunto: New Version Notification for draft-contreras-alto-ietf-nef-00.txt


A new version of I-D, draft-contreras-alto-ietf-nef-00.txt
has been successfully submitted by Luis M. Contreras and posted to the IETF 
repository.

Name:   draft-contreras-alto-ietf-nef
Revision:   00
Title:  Considering ALTO as IETF Network Exposure Function
Document date:  2021-10-25
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/archive/id/draft-contreras-alto-ietf-nef-00.txt
Status: https://datatracker.ietf.org/doc/draft-contreras-alto-ietf-nef/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-contreras-alto-ietf-nef


Abstract:
   This document proposes ALTO as the means for exposure of underlay
   network capabilities for multiple overlays on top of the network.




The IETF Secretariat





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

Re: [alto] Meeting Info for Oct 5, 2021

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all,

@Danny -- Welcome back!

@Kai – if time permits, I would like to present the draft skeleton for 
“Considering ALTO as IETF Network Exposure Function”


Best regards

Luis



De: alto-weekly-meet...@googlegroups.com  
En nombre de Y. Richard Yang
Enviado el: lunes, 4 de octubre de 2021 19:11
Para: Danny Lachos 
CC: alto-weekly-meet...@googlegroups.com; IETF ALTO ; Ingmar 
Poese 
Asunto: Re: [alto] Meeting Info for Oct 5, 2021

Hi Danny,

Thanks for the kind note. It is always wonderful to work with you!

Richard

On Mon, Oct 4, 2021 at 11:21 AM Danny Lachos 
mailto:dlac...@benocs.com>> wrote:

Hello ALTOers,

Finally, I am in Berlin

Now here at Benocs, I will continue to participate in the WG discussions & 
weekly meetings



Talk to you tomorrow


On 04.10.21 16:26, kai...@scu.edu.cn wrote:

Dear all,



This is a friendly reminder that we will have our ALTO weekly meeting at 9:00 
am US EST (3:00 pm CET and 9:00 pm Beijing Time) on Tuesday, October 5, 2021.



Reminder:

We will have 3 weekly meetings before the draft submission deadline (Oct 25) 
and 5-6 weekly meetings before IETF 112 (Nov 6-12).



Agenda:

- Planning of weekly meetings before IETF 112

- Trial editorial session for path vector



Bridge:

https://yale.zoom.us/my/yryang



Best,

Kai


___

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


--
--
 =
| Y. Richard Yang mailto:y...@cs.yale.edu>>   |
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
--
You received this message because you are subscribed to the Google Groups 
"alto-weekly-meeting" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
alto-weekly-meeting+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/alto-weekly-meeting/CANUuoLqh2e%2Bu1WoOijExgM%3DS4AtWM%3DAKZrc0GE_hG9unwO%3DqEw%40mail.gmail.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

Re: [alto] charter-ietf-alto-04-01

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Lars, all,

Apologies for commenting late, I was on holidays.

I would like just to comment on the activities we are doing in Telefonica with 
ALTO. The objective we pursue is to automate the retrieval of network topology 
for optimizing the delivery of video as primary service, targeting additional 
services in the future.

Telefonica has its own CDN development, serving VoD and live TV, and adding 
contents from 3rd parties. By leveraging on ALTO and interfacing the CDN with 
ALTO we try to solve two main issues:


(1)to retrieve an up-to-date view of the network topology, that is, where 
the IP prefixes from the end-users are attached. This is changing along tie 
because the reusing of the IP addressed, for instance in the migrations from 
xDSL to FTTH, consolidation of central offices, etc (similar situation happens 
for mobile service). By now, the actualization of the information is done 
manually, every 6 months, creating inefficiencies and being prone to errors.

(2)to optimize the delivery of service to those customers by taking into 
consideration network information (topology, cost map, and in the future 
advanced info such as available bw), not only application-side inputs (such as 
server loads, etc)

We have completed a 1st PoC leveraging on OSPF. Now we are moving the 
validation to a more complex scenario from one of the operational companies of 
Telefonica, which leverages on IS-IS and which has end-to-end MPLS 
connectivity, but not IP continuity (this implies for instance to handle 
several AS’s plus other complications). The objective is to extend the solution 
based on ALTO to the other operational companies of Telefonica along the time, 
in Europe and Latin America.

In summary, ALTO can help to automate hard tasks related to network operation 
and optimize the utilization of the network, benefiting both users and the 
operator itself.

Same ideas can be easily extrapolated for services we now foresee (refer to 
service edge draft, for instance), or to evolutions of existing content 
services (XR/AR). In this respect the value of ALTO is tremendously high.

Best regards

Luis

__
Dr. Luis M. Contreras

Transport & IP Networks
Systems and Network Global Direction
Telefónica I+D / 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

De: alto  En nombre de Y. Richard Yang
Enviado el: martes, 24 de agosto de 2021 16:43
Para: Lars Eggert 
CC: IETF ALTO ; alto-cha...@ietf.org; Qin Wu 
; The IESG 
Asunto: Re: [alto] charter-ietf-alto-04-01

Hi Lars,

I saw your comment and have to chime in.

I have to respectfully disagree with your assessment: "Overall, I remain 
unconvinced that there is sufficient work/interest in this space to warrant a 
chartered WG." I am not sure if you attended the NAI@SIGCOMM'21 Workshop 
yesterday. There was clearly a huge interest and work in the space. The title 
of Amin Vahdat's talk is "Application-Defined Networking", as "It now opens the 
next wave of opportunities toward Application-Defined Networking, Where 
application efficiency metrics drive network control configuration policy, 
Integration into compute and storage infrastructure→ job placement, 
replication, Visibility into distributed systems structure, including Load 
Balancing, Thread Scheduling, RPCs, RDMA, and Collectives", using the sentences 
from the keynote. Now, let's go more specific to ALTO and to engineering. The 
work of Flow Director, in the scope of ALTO, was reported in CoNEXT'19 
(https://gsmaragd.github.io/publications/CoNEXT2019/). Luis mentioned ongoing 
deployment efforts at Telefonica; there is the on-going deployment of ALTO at 
the Greater Bay Network, which is a large, among the most-advanced networks 
covering Shenzhen, Hong Kong; there is the ongoing MoWIE work, based on and the 
need to extend ALTO, by China Mobile and Tencent...  I agree that ALTO is far 
far far from taking over the world, but I have a totally different assessment.

If when you say that there is not sufficient work, you mean that *the charter* 
does not include sufficient work. This is by design and good guidance: the WG 
substantially limits the scope of the recharter to consolidate the WG in the 
short term, and there was a huge disappointment from many industry parties on 
the removing of their work from the charter discussions---not sure if you 
attended some of the recharter discussions, there was a large amount of 
proposed work but they were mostly removed.

Please see below.

On Tue, Aug 24, 2021 at 9:29 AM Lars Eggert 
mailto:l...@eggert.org>> wrote:
Hi,

On 2021-8-24, at 16:07, Qin Wu mailto:bill...@huawei.com>> 
wrote:
> Thank you for reviewing the proposed re-charter of the ALTO working group.

> > It's not clear to me why this effort would need a chartered 

Re: [alto] A new draft draft-liu-alto-can-usecase-00 for discussion and comments

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Peng,

Thanks for sharing. Looking at the figure of the CAN framework I can see 
depicted multiple components interacting with the ALTO server: Service 
Orchestration, Computing OAM, Routing Management and Resource Management. This 
brings to my mind a number of questions:


-  Do you foresee an individual interaction per component with the ALTO 
Server? If so, what would be the specific interaction per component and to what 
extend such interaction would imply some extension?

-  Would not be more practical to consider a single ALTO Client as part 
of the Computing and Network Management Layer aggregating all the requests 
towards the ALTO Server? This also could decouple the solution from a specific 
CAN architecture

-  In the scheduling section, you mention the possibility of retrieving 
real time information. How far the information could be “real-time”? I mean, in 
the way ALTO works (i.e., collecting information from protocols such BGP with 
certain timers) the notion of “real-time” could be relative. Would the aging of 
that information sufficient to ensure the “real-time” needs? Would it be needed 
any other mechanisms to shorten the period of information refreshment?

Best regards

Luis

De: alto  En nombre de Peng Liu
Enviado el: miércoles, 21 de julio de 2021 5:39
Para: alto 
Asunto: [alto] A new draft draft-liu-alto-can-usecase-00 for discussion and 
comments

Hi All,

A new draft draft-liu-alto-can-usecase-00 has been 
submitted（https://www.ietf.org/archive/id/draft-liu-alto-can-usecase-00.txt）
Since some work of computing related service deployment and routing have been 
proposed in IETF and ITU, this draft describes a new network scenario and 
architecture considering computing-related properties, and assumes that Alto 
could be used to help realize the deployment of services, and to assist in the 
selection of service nodes.
Any comments are welcome.

Regards,
peng

Peng Liu | 刘鹏
China Mobile | 移动研究院
mobile phone：13810146105
email:  liupeng...@chinamobile.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

Re: [alto] I-D Action: draft-hzx-alto-network-topo-00.txt

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Cheng Zhou,

Thanks for sharing. I see interesting aspects on the draft. Let me share my 
thoughts.

- part of the draft is about how ALTO can get topological information. Today we 
can retrieve such information through BGP and BGP-LS, and with that build both 
network and cost map. Your proposal of using NETCONF would be a complementary 
(or alternative) way of doing so, which is fine. What I'm wondering is the 
following. We can assume that in a network like that, i.e. leveraging or 
supporting NETCONF, we will have a controller. So, why do not assume that the 
ALTO collects the information from a controller rather than from the devices? 
Not sure if there could be an issue with many components retrieving info from 
the devices simultaneously, so the controller could unify that process.

- In line with the previous comment, relaying on NETCONF could not be 
sufficient for having all the information. Could be the case that some vendors 
do not support the specific model, or even that part of the network does not 
support NETCONF at all. This issue is not present with BGP, and most probably 
not present with BGP-LS, so probably it could be needed to yet relay on BGP and 
BGP-LS for ensuring full collection of the info. Thus some kind of 
reconciliation between the different databases would be needed. Do you have any 
insight on this?

- it is interesting the approach of retrieving topologies other than the 
physical one (I mean, VPN topology). This opens an interesting aspect to 
explore which I'm particularly interested in. For instance, putting together 
such overlay view with the performance metrics being proposed in ALTO could be 
certainly interesting. Other situations can be also of interest. I will think 
about that and come back with some ideas.

Best regards

Luis

-Mensaje original-
De: alto  En nombre de Cheng Zhou
Enviado el: miércoles, 21 de julio de 2021 5:51
Para: alto@ietf.org
Asunto: Re: [alto] I-D Action: draft-hzx-alto-network-topo-00.txt

Hi, All:

As we know, the CDN makes use of an ALTO server to choose a better CDN 
surrogate. However CDN may not be able to passively listen to routing protocol, 
nor may have access to other network topology data (e.g., inventory databases).
Based on our analysis, CDN is built on top of underlying network which runs 
these routing protocols and the network topology can be gathered via BGP-LS or 
NETCONF YANG. I2RS working group have published various network topology models 
such as L3 topology model, L2 topology model. We are wondering whether we can 
use NETCONF protocol to collect these network topology data and translate into 
ALTO map data.
Here is the relevant draft we proposed in ALTO working group:
https://datatracker.ietf.org/doc/html/draft-hzx-alto-network-topo-00.txt
Please let us know if you have any comments or suggestions.

Thanks and Regards,
Cheng Zhou

-Original Mail-
发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表
internet-dra...@ietf.org
发送时间: 2021年6月25日 11:40
收件人: i-d-annou...@ietf.org
主题: I-D Action: draft-hzx-alto-network-topo-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Network Topology data retrieval using ALTO
protocol
Authors : Hanshu Hong
  Cheng Zhou
  Chongfeng Xie
  Qiufang Ma
Filename: draft-hzx-alto-network-topo-00.txt
Pages   : 12
Date: 2021-06-24

Abstract:
   RFC8345 introduces an abstract YANG data model to represent network
   topologies.  This document uses ALTO protocol to provide access to
   network Topology data such as L3 topology data , data center network
   topology data, flexible enough to enable querying of specific and
   possibly aggregated data.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hzx-alto-network-topo/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-hzx-alto-network-topo-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or 
ftp://ftp.ietf.org/ietf/1shadow-sites.txt



___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto



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 

Re: [alto] Meeting Info for May 4, 2021

[LUIS MIGUEL CONTRERAS MURILLO]

My apologies but I’m not sure if I will be able to connect today. Sorry, Luis

De: alto-weekly-meet...@googlegroups.com  
En nombre de Qiao Xiang
Enviado el: martes, 4 de mayo de 2021 3:47
Para: kaigao 
CC: IETF ALTO ; alto-weekly-meet...@googlegroups.com
Asunto: Re: [alto] Meeting Info for May 4, 2021

Dear all,

I have a conflict personal appointment that may run long. So I probably will 
miss part of the meeting.


Best
Qiao

On Mon, May 3, 2021 at 10:12 PM mailto:kai...@scu.edu.cn>> 
wrote:

Dear all,



This is a friendly reminder that we will have our weekly ALTO meeting at 9:00 
am US EST (3:00 pm CET and 9:00 pm Beijing Time) on Tuesday, May 4th, 2021.



Agenda:



- Follow-up on the recharter discussion in the last meeting

- NAI workshop (topics and submissions)



Bridge:



https://yale.zoom.us/my/yryang



Looking forward to seeing you in the meeting!



Best,

Kai
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


--
Qiao Xiang
Professor, Xiamen University
--
You received this message because you are subscribed to the Google Groups 
"alto-weekly-meeting" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
alto-weekly-meeting+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/alto-weekly-meeting/CAOB1xS8yupCZJxfVTiuO9RzFuLnm1WLMVnpmK1kPW_mGm_cBHA%40mail.gmail.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

Re: [alto] Meeting Info for Apr 27, 2021

[LUIS MIGUEL CONTRERAS MURILLO]

Dear all,

I will connect today 30 min late because an unavoidable conflict.

Best regards

Luis

De: alto  En nombre de kai...@scu.edu.cn
Enviado el: martes, 27 de abril de 2021 2:15
Para: alto@ietf.org; alto-weekly-meet...@googlegroups.com
Asunto: [alto] Meeting Info for Apr 27, 2021


Dear all,



This is a friendly reminder that we will have the weekly ALTO meeting at 9:00 
am US EST (3:00 pm CET and 9:00 pm Beijing Time) on Tuesday, April 27, 2021.



Agenda:



- NAI workshop (potential submissions)

- IETF 111 planning



As usual, if anyone wants to discuss another topic, please do not hesitate to 
let me know.



Bridge:



https://yale.zoom.us/my/yryang



See you in the meeting!



Best,

Kai



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

Re: [alto] Meeting Info for Mar 16, 2021

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all,

My apologies, I will not be able to connect today due to a conflict by the 
change of time.

I will plan for next week. Sorry for that.

Best regards

Luis

De: alto  En nombre de kai...@scu.edu.cn
Enviado el: lunes, 15 de marzo de 2021 16:10
Para: Jensen Zhang 
CC: alto-weekly-meet...@googlegroups.com; IETF ALTO 
Asunto: Re: [alto] Meeting Info for Mar 16, 2021

Hi Jensen,

Thanks for the notice!

Best,
Kai

2021-03-15 22:59:49"Jensen Zhang" wrote:
Hi,

I need to mention that daylight saving time began last Sunday in the US. If we 
still align the time with US EST, the meeting time should be 2:00 pm CET and 
9:00 pm Beijing time.

Best,
Jensen


On Mon, Mar 15, 2021 at 10:40 PM mailto:kai...@scu.edu.cn>> 
wrote:

Dear all,



This is a friendly reminder that we will have the ALTO weekly meeting at 9:00 
am US EST (3:00 pm CET, 10:00 pm Beijing Time) on Tuesday, Mar 16, 2021.



Agenda:

- Summary & Planning for next steps



Bridge:

https://yale.zoom.us/my/yryang



If anyone wants to discuss another topic, please use the agenda bash or send me 
an email.



Best,

Kai
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto



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

[alto] Bringing operation automation cases to the list

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all,

Apologies for the time taking to post the operation automation cases to the 
list.

As part of the re-charter discussion, for 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

Case 2. Usage of ALTO for combined compute and network selection (e.g., for 
optimal edge computing service placement)

Case 3. Extensions to ALTO for acting as aggregator of information from 
different sources (e.g., TEDB, LSP DB, etc)

Case 4. Overlay / underlay integration supported by ALTO (e.g., CDN)

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

Re: [alto] Meeting info for Jan 19, 2021

[LUIS MIGUEL CONTRERAS MURILLO]

Dear all,

Apologies but I will not be able to join today. I will synch up with whatever 
notes could be generated after.

Best regards

Luis

De: alto  En nombre de kai...@scu.edu.cn
Enviado el: martes, 19 de enero de 2021 3:00
Para: alto@ietf.org; alto-weekly-meet...@googlegroups.com
Asunto: [alto] Meeting info for Jan 19, 2021


Dear all,



This is a friendly reminder that we will have an ALTO weekly meeting at 9:00 am 
US EST (3:00 pm CET and 10:00 pm Beijing Time) on Tuesday, Jan 19th, 2021.



Agenda:



- Progress of WG drafts and individual drafts

- IETF 110 registration

- NAI workshop



If anyone wants to present or lead another topic, please let me know or use the 
agenda bash.



Bridge: https://yale.zoom.us/my/yryang



Best,

Kai



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

Re: [alto] Meeting minutes for Dec 8, 2020

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Kao, all,

Yesterday it was bank holiday in Spain, so I couldn’t attend the meeting. My 
apologies.

A couple of comments after reading the minutes of the meeting:

1/ W.r.t. the integration of ALTO and Telefonica CDN we will start integrating 
ALTO with a mock-up of one of the operations of Telefonica this month. The way 
in which the CDN will get up-to-date information of network status is not yet 
100% defined, but clearly SSE is a potential path to follow.

2/ Regarding the integration with cellular, I would like to bring your 
attention to the recent specification from ETSI MEC on integration with 5G 
networks [1]. Even if the case is not the same, the potential ways of 
integration could be similar.

Best regards

Luis

[1] ETSI GR MEC 031, “MEC 5G Integration”, v2.1.1, October 2020. 
https://www.etsi.org/deliver/etsi_gr/MEC/001_099/031/02.01.01_60/gr_MEC031v020101p.pdf

De: alto  En nombre de kai...@scu.edu.cn
Enviado el: miércoles, 9 de diciembre de 2020 13:27
Para: alto@ietf.org; alto-weekly-meet...@googlegroups.com
Asunto: [alto] Meeting minutes for Dec 8, 2020


Dear all,



Please find below the meeting minutes for the weekly meeting on Dec 8.



Please let me know if anything important is missing or misinterpreted. Thanks!



Best,

Kai




Open issues:

- Jensen will post the link to his slides and bring the discussion to the 
mailing list on how to handle the overlapping of operation automation and 
general extension
- Get volunteers to interact with other meetings/forums to present the designs 
of ALTO and get feedback
- Collect meeting information for related forums/workshop chances

Discussion 1
--

Jensen presented the update on the development of alto server. It exposes some 
API for ALTO operators to create/read/update/delete ALTO information resources. 
It also supports multipart messages. An ALTO information resource can access 
multiple data sources: internal/external/reactive.

He also presented the current design of the API using YANG.

Discussions:
Richard: Is this the backend API for the ALTO server?
Jensen: Yes.
Qin: This looks like a data model. The backend will be part of the ALTO server.
Richard: What is the purpose of this model? One purpose of the model is to give 
a YANG model for ALTO protocol?
Kai: I guess the question is why providing the API using the YANG language 
instead of following the JSON-based data models which is used by the frontend 
ALTO API?
Richard: The model is API exposed by the ALTO server to the backend.

Jensen presented the example to create an ALTO network map based on BGP 
information.

Discussions:
Richard: How do you configure the BGP information?
Jensen: You specify the algorithm and the parameters of the algorithm.

Jensen presented handling dynamicity. There are two types of dyanmicity: 
network dynamicity and demand dynamicity. He presented the use case of 
Telefonica CDN where the ALTO client need to detect potential prefix changes 
and subscribe accordingly. Solution 1 is to extend the SSE extension to allow 
clients update existing subscriptions. The second extension is to specify 
conditions/constraints to specify which flows/metrics it is interested in.

Discussions:
Sabine: There is some overlapping with general extension.
Qin: Luis proposed to separate the automation in two parts: southbound and 
northbound. We need to figure out how to handle the overlapping.
Richard: We should invite Lyle and Farni.

Meeting item 2
--

Chunshan mentioned that O-ran can provide a wide range of information but are 
not widely deployed. In 3gpp, only the CP is used but network service chaining 
headers may be used. How should we move forward given the current 3gpp 
standards?

Discussions:
Sabine: Regarding cellular information, if we want to expose them, even if we 
use acceleration mechanisms (such as IB), the question is still is, we should 
define the needs for the application? What pace do they need? What delay do 
they tolerate? We should sort out cases where an application really need 
cellular information update which require transport-speedup mechanisms. The 
first step is to find doable use cases (metrics and applications that need 
them).
Richard: Your concern is that 3gpp may not provide a lof of information. Given 
that Tencent may be a major user of the system, you may put demands on what 
information should be exposed, will it be provided by 3gpp?
Chunshan: 3gpp wants to get information from the clients instead of allowing 
clients pulling information from the network. A lot of key vendors are 
reluctant to provide information to outside.
Richard: Applications oftentimes have choices. My app can use multiple 
operation modes.
Chunshan: 3gpp can expose but only limited information.
Richard: Suggestion: First we initiate the design for O-ran, the more flexible 
model. Second, we attend 3gpp meetings and have discussions.
Chunshan: Maybe we can present the need of information as the view of the IETF 
to 

Re: [alto] ALTO recharter: proposed item - General ALTO protocol extensions

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Sabine,

Some few comments, that have been actually mentioned by me during this weekly 
ALTO regular call.

.- I think the General Protocol Extension item for re-charter is a good place 
holder for maintenance and improvements of current protocol. For instance, I 
think that aspects such as the use of BGP communities (see 
draft-contreras-alto-bgp-communities) fits well in some item like this.

.- Regarding the text itself, I do foresee use cases that could apply e.g. 
indications of SLA characteristics for discriminating the information 
retrieved. For instance, applications tolerant to the delay (e.g. database 
backups) could receive different information from those time critical.

Hope this is aligned with your view.

Best regards,

Luis

De: alto  En nombre de Randriamasy, Sabine (Nokia - 
FR/Paris-Saclay)
Enviado el: lunes, 16 de noviembre de 2020 18:36
Para: IETF ALTO 
Asunto: Re: [alto] ALTO recharter: proposed item - General ALTO protocol 
extensions

Hello,

Please find below a revision of the proposed definition paragraph.
This WG item is further detailed in the Google doc available here (page 19/25):
https://docs.google.com/document/d/1qP9jf-CMXvNiEE3YAnApTczAE4QkBW23Q1Eg99uOaEQ/edit

Thanks,
Sabine


General protocol extensions to convey a richer set of attributes allowing to 
determine not only "where" and "when" to connect but also under which 
conditions. Such additional information will be related both to entities (e.g. 
conveying time-averaged server load in data center supported applications) and 
to path costs (e.g. ALTO path cost value depending on conditions such as 
real-time network indications or SLA or policy or access-type or indicator 
type).

The working group will specify such extension in coordination with both other 
ALTO working group items and IETF working groups that have a focus on the 
related use cases.  The scope of extensions is not limited to those identified 
by the WIs and WGs, but is limited by the criteria set out below.



From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
Sent: Monday, November 16, 2020 6:16 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>;
 IETF ALTO mailto:alto@ietf.org>>
Subject: RE: ALTO recharter: proposed item - General ALTO protocol extensions

Dear all,

The paragraph below is proposed to define the WG item on "general protocol 
extensions".
As the purpose of this work item is also to support other WG items that may 
need these extensions, your feedback again is more than welcome.
Thanks,
Sabine

General protocol extensions to convey a richer set of cost attributes allowing 
to determine not only "where" and "when" to connect but also under which 
conditions. Such additional information will be related both to entities (e.g. 
conveying time-averaged (cache storage capacities and)  server load in data 
center supported applications) and to ALTO path costs (e.g. ALTO path cost 
value depending on conditions such as real-time network indications or SLA or 
policy or access-type or indicator type).

The working group will specify such extension in coordination with both other 
ALTO working group items and IETF working groups that have a focus on the 
related use cases.  The scope of extensions is not limited to those identified 
by the WIs and WGs, but is limited by the criteria set out below.


From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
Sent: Tuesday, November 10, 2020 7:24 PM
To: IETF ALTO mailto:alto@ietf.org>>
Subject: [alto] ALTO recharter: proposed item - General ALTO protocol extensions

Dear all,

Please find below a WG item proposal for "general ALTO protocol extensions", on 
which your feedback and suggestions will be more than welcome.
Thanks,
Sabine

-- Context: the current ALTO charter
o Extends the path cost values in several directions:
  - single to array of several cost metrics => allows apps to 
decide upon several metrics and make decision compromise
  - single cost value to array if time dependent cost values => 
allow apps to determine when to connect
o Extends endpoints to entities on which properties are defined

-- Basic Issues
+++  Issue 1: Some path cost values may depend on "contextual parameters" such 
as access type, SLA, policy or other indicators provided by network. In 
particular:
  - There may be different possible paths between source and 
destination, where some paths may or may not meet Application QoE or policy 
constraints. The Applications would like to see which path is most suitable.
  - Contextual parameters may be available at frequencies that are 
different from ALTO information frequency. For example, Cost on PID-Cell1 may 
differ, 

Re: [alto] Welcome Qin Wu

[LUIS MIGUEL CONTRERAS MURILLO]

+1

Luis

De: alto  En nombre de Y. Richard Yang
Enviado el: miércoles, 11 de noviembre de 2020 5:47
Para: Martin Duke ; Qin (Bill) Wu 
CC: IETF ALTO 
Asunto: Re: [alto] Welcome Qin Wu

Thanks a lot for choosing a wonderful chair for ALTO, Martin!

Qin: It is wonderful to have you and work with your guidance!

Richard

On Mon, Nov 9, 2020 at 10:48 PM Martin Duke 
mailto:martin.h.d...@gmail.com>> wrote:
Hello ALTO,

I'm pleased to welcome Qin Wu as the newest working group chair, effective 
immediately. Qin is and active participant in ALTO and an experienced chair.

We will have three chairs at IETF 109. Shortly afterwards, one of the current 
chairs will step down. As we complete the current milestones, I will appoint a 
second chair to free both Jan and Vijay to move on to other things.

See you next week,
Martin
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


--
--
 =
| Y. Richard Yang mailto:y...@cs.yale.edu>>   |
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =



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

Re: [alto] Review of draft-ietf-alto-path-vector-11

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Richard,

Thanks for the summary. It is ok for me.

Best regards

Luis

De: Y. Richard Yang 
Enviado el: lunes, 2 de noviembre de 2020 23:04
Para: LUIS MIGUEL CONTRERAS MURILLO 
CC: alto@ietf.org
Asunto: Re: [alto] Review of draft-ietf-alto-path-vector-11

H Luis,

Thanks a lot for the wonderful review! As we upload the revision, here is a 
summary of the changes that we make. Please see inline to see if you are OK. 
After you approve, we will finalize all.

On Sun, Oct 25, 2020 at 5:01 PM LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
 wrote:
Hi all,

I have performed a review of the draft, with comments as follows:

/* Technical comments */
.- Section III Terminology – Path Vector bullet. Please, rephrase the 
description, it is hard to understand, especially the second sentence. Not 
clear.

OLD
 Path Vector: A Path Vector, or an ANE Path Vector, is a JSON array
  of ANE Names.  It conveys the information that the path between a
  source and a destination traverses the ANEs in the same order as
  they appear in the Path Vector.

NEW

Path Vector: A Path Vector, or an ANE Path Vector, is a JSON array
  of ANE Names.  This extension (i.e., ALTO path vector extension) 
generalizes
  BGP path vector, where a standard BGP path vector specifies the sequence 
of
  autonomous systems from a source to a destination. In this extension, the 
path
  vector specifies the sequence of general ANEs computed according to a user
  request.

.- Section 4.2 – it refers to recent use cases, but it is not relevant how 
recent are the use cases (in fact, for this, see my next comment). So I would 
suggest to remove any reference to recent either in the title or the text. 
Simply refer to use cases.

Very good point. We have removed the word "recent" in the title and the text.


.- Section 4.2 – there is a reference to an expired I-D which last from 2013 
(so pretty old). I would suggest to remove such a reference since somehow the 
potential use cases it refers should be present here.

Sounds good. Yes. Removed.

.- Section 5.1.3, 2nd paragraph – “… and the response must return and only 
return the selected properties …” – two comments here: (1) must should be MUST 
in this context?; (2) “… and only return …” – probably redundant, better either 
remove or rephrase as “MUST/must only return”.

Good point.

OLD
   "... and the
   response must return and only return the selected properties for the
   ANEs in the response."



NEW
  "... and the
   response MUST include and only include the selected properties specified in 
the filter. "

.- Figure 4 – the figure shows two response messages, but some questions arise 
in this respect: (1) what happens if second response is not received?; (2) what 
happens if only the second response is received? Is it silently discarded?; (3) 
is there some expected timer for accounting time-out in the responses? It is 
mentioned in bullet 2 that there could be some processing among messages, so it 
can be assumed that some maximum delay could happen between both responses.

Good point.

OLD
  Specifically, the
   Path Vector extension requires the ALTO client to include the source
   and destination pairs and the requested ANE properties in a single
   request, and encapsulates both Path Vectors and properties associated
   with the ANEs in a single response, as shown in Figure 4.

NEW

  Specifically, the
   Path Vector extension requires that (1) the ALTO client include the source
   and destination pairs and the requested ANE properties in a single
   request; (2) the ALTO server MUST return a single response with the Path 
Vectors followed by the
   properties associated with the ANEs in the Path Vectors, as shown in Figure 
4.

In addition, in 5.3.3, we add the specification on the essential completeness 
issue:

OLD
5.3.3. Order of Part Message

NEW
5.3.3. Order and Completeness of Part Message

We add a sentence at the end of 5.3.3

   The ALTO server MUST always send the complete response including both parts. 
The client should check the completeness of response and implementing a timeout 
mechanism to avoid hanging issues.


.- Section 6.2.4, last paragraph - Hard to understand, not clear. Please, 
rephrase/review.

OLD
   Specifically, the defining resource of ephemeral ANEs is the Property
   Map part of the multipart response.  The defining resource of
   persistent ANEs is the Property Map on which standalone queries for
   properties of persistent ANEs are made.

NEW
   Note that there are two types of ANEs (see Section 5.1.2): ephemeral ANEs and
   persistent ANEs. For ephemeral ANEs, the defining resource is the Property
   Map part of the multipart response; the defining resource of
   persistent ANEs is the Property Map on which standalone queries for
   properties of persistent ANEs are made.

.- Section 6.4.2, Intended semantics text – it is not clear the associat

Re: [alto] Meeting Info for Oct 27, 2020

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Kai, all,

Unfortunately I will not be able to attend tomorrow’s meeting. I will synch up 
with the notes after the meeting.

Best regards

Luis

De: alto  En nombre de kai...@scu.edu.cn
Enviado el: lunes, 26 de octubre de 2020 14:01
Para: alto-weekly-meet...@googlegroups.com; alto@ietf.org
Asunto: [alto] Meeting Info for Oct 27, 2020


Hi everyone,



Just a reminder that we will have a weekly meeting at 9:00 am US EST, Oct 27, 
2020.



Agenda:



1. Updates on the WG documents

2. Recharter discussion



If anyone wants to present or lead a discussion, please let me know.



Bridge: https://yale.zoom.us/my/yryang



Best,

Kai



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

[alto] Review of draft-ietf-alto-path-vector-11

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all,

I have performed a review of the draft, with comments as follows:

/* Technical comments */
.- Section III Terminology - Path Vector bullet. Please, rephrase the 
description, it is hard to understand, especially the second sentence. Not 
clear.
.- Section 4.2 - it refers to recent use cases, but it is not relevant how 
recent are the use cases (in fact, for this, see my next comment). So I would 
suggest to remove any reference to recent either in the title or the text. 
Simply refer to use cases.
.- Section 4.2 - there is a reference to an expired I-D which last from 2013 
(so pretty old). I would suggest to remove such a reference since somehow the 
potential use cases it refers should be present here.
.- Section 5.1.3, 2nd paragraph - "... and the response must return and only 
return the selected properties ..." - two comments here: (1) must should be 
MUST in this context?; (2) "... and only return ..." - probably redundant, 
better either remove or rephrase as "MUST/must only return".
.- Figure 4 - the figure shows two response messages, but some questions arise 
in this respect: (1) what happens if second response is not received?; (2) what 
happens if only the second response is received? Is it silently discarded?; (3) 
is there some expected timer for accounting time-out in the responses? It is 
mentioned in bullet 2 that there could be some processing among messages, so it 
can be assumed that some maximum delay could happen between both responses.
.- Section 6.2.4, last paragraph - Hard to understand, not clear. Please, 
rephrase/review.
.- Section 6.4.2, Intended semantics text - it is not clear the association of 
persistent to ephemeral. Why is this? What is the purpose?
.- Section 6.4.2, last paragraph - The value of ephemeral is provided, but what 
would be the value of persistent one?
.- Section 9.3, 1st and past paragraph - they seem inconsistent since in one 
hand the first claims incompatibility while the second claims compatibility. 
Please, review them.
.- Section 9.4 - When used with the calendar extension, should the ANE be 
always persistent? I mean, same ANE for all the time views, otherwise could not 
properly work. Please, clarify.

/* Editorial comments */
.- Section I Introduction, pag. 5, penultimate paragraph - "... Path Vector 
response involve two ALTO ..." -> "... Path Vector response involves two ALTO 
..."
.- Section I Introduction, pag. 5, last paragraph - "... the rest of the 
document are organized ..." -> "... the rest of the document is organized ..."
.- Section III Terminology stands that the document extends the terminology 
used in RFC 7285 and in Unified Properties draft. This implies some precedence 
in the edition of the documents as RFCs, if they finally progress to that 
stage. So I would recommend to add a note for RFC Editor mention that 
precedence (note to be remove once the document becomes a RFC).
.- Section 5.1 - the text (2nd paragraph) auto-refers to section 5.1. 
Redundant, better to remove.
.- Section 5.2 - 1st paragraph - correct -> correctly
.- Section 5.3, last sentence before Figure 4 - "... the ANEs in a single 
response ..." -> "... the ANEs in an additional response ..."
.- Section 6.6 - The second paragraph starts with NOTE; probably better to 
rephrase writing it as a normal paragraph.
.- Section 9.2, last sentence - "compatible" -> "compatibility"

Best regards

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 

[alto] Review for draft-ietf-alto-unified-props-new-12

[LUIS MIGUEL CONTRERAS MURILLO]

Dear all,

Please, find here below the review for the Unified Properties draft.

/* General comments */
.- Section 2 - Requirements language - as general comment, the usage of words 
such as MUST, MAY, etc should be reviewed in all of the occurrences in the 
text. In some of them they do not appear in capital letters, so not clear if 
this statements apply or not. Examples of this are: "must" in 2nd paragraph of 
section 3.2; "must" in 2nd paragraph of section 4.1; "may" in 1st paragraph of 
section 4.3; etc.
.- References to the need of registering some items at IANA - it is not clear 
to me if this can be left as it is or if some values have to be proposed in the 
draft, or at least marked in the text with the idea of substituting such marks 
by values once IANA register the items. If that is the case, it would be 
advisable to include (maybe as an annex) a summary table compiling all the 
items that are expected to be registered. Would it not be part of section 12?
.- Along the text it is frequent to find references to other sections before or 
afterwards. Acknowledging that this could be necessary, it would help the 
reader to have some summary table (or any other way, like a figure) where the 
different aspects could be listed beforehand, in such a way that the reader can 
use it as a kind of map for navigating through the document. I understand it is 
not easy, so take it as a suggestion for making the document more readable. For 
instance, some way of showing the relationship among terms in the Terminology 
section.
.- Section 3 presents the basic features of the unified properties while the 
advanced ones are in section 4. How these extensions co-exist? Are they 
incremental? What is the reason from presenting them in separate sections? Is 
it possible to have the basic ones without the advanced features?
.- Both Section 10 and Appendix A present examples. Would not make sense to 
move all he examples either to one place or the other?

/* Particular comments */
.- Section 1 - Introduction, page 4, 2nd paragraph - "... recent ALTO use cases 
show ..." -> it would be good to be more explicit by listing the use cases that 
are being referred to.
.- Section 1 - Introduction, page 5, 1st bullet - fix reference for [REF 
path-vector]
.- Section 1 - Introduction, page 5, 3rd bullet - "... POST-mode... that 
returns ..." -> would not be "sets" instead of "returns"?
.- Section 1 - Introduction, page 5, 1st paragraph - "extensible" -> 
"augmentable" ??
.- Section 1.1 - Terminology - fix the text marked as TBC
.- Section 2 - Requirements language, 1st paragraph - fix the text marked as 
TODO.
.- Section 3, 1st paragraph - The reference to the assumption of familiarity 
with ALTO protocol is redundant with the last sentence of section 1 (just 
before section 1.1 title)
.- Section 3, 1st paragraph - "... ALTO Entities, entities for short" -> "... 
ALTO Entities, or entities for short"
.- Section 3.2.2, 1st paragraph - the sentence "An entity domain name ..." is 
hard to understand. Please, revisit and simplify (maybe shortening or dividing 
it).
.- Section 3.3, 1st paragraph - "Simularly" -> "Similarly"
.- Section 3.3, bullets in page 9 - is there any inventory of registered types? 
Are only those provided here as examples?
.- Section 4.2, penultimate paragraph - "Example resource specific..." -> 
"Example of resource specific..."
.- Section 4.4, 2nd paragraph - it would be interesting to perform queries and 
marking properties that could exclude or filter the entities. For instance to 
get a list of entities compliant with some property but excluding those that 
are compliant with another one.
.- Section 4.4.3, 1st paragraph - "... inherits no more than one property ..." 
<- why not more than one?
.- Section 4.4.3, 1st paragraph, last sentence - how is it applied? It would be 
interesting to add some example.
.- Section 4.5, 1st paragraph - "Therefore an ALTO server ... specifies the 
properties ..." <- how this advertisement is made?
.- Section 4.5, 2nd paragraph - expand IRD as first occurrence in the text.
.- Section 4.5, 2nd bullet - "... a list of the names ..." <- names or types?
.- Section 4.6, 1st paragraph - "To this end, he ..." -> "To this end, the ..."
.- Section 4.6, 1st paragraph - "The syntax of the entity domain identifier ... 
allows the client to infer ..." -> would it not be better to follow some rule 
instead of inferring if it is resource specific or not?
.- Section 4.6, last paragraph - is it necessary to have always a Defining 
Information Resource for each entity domain?
.- Section 4.6.1, page 16, paragraph "A fundamental attribute ..."- I don't 
understand the paragraph
.- Section 4.7, 1st paragraph -- "The PID value for an IPv4 ..."- I would 
suggest to rephrase, hard to understand.
.- Section 4.7, 2nd paragraph - "... needs to be aware of aware of appropriate 
..." -> "... needs to be aware of appropriate ..."
.- Section 5, title - "... Basic Data Type ..." -> here it is mentioned 

Re: [alto] Interested in reviewing unified-props? And other drafts as well

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Vijay,

My apologies for my lack of responsiveness, I have had a number of subsequent 
events impeding me to concentrate on this.

My answer is yes, and I take October 9th as hard deadline for providing my 
review. Is that correct?

Apologies again for my late expression of interest on performing it.

Best regards

Luis

De: alto  En nombre de Vijay Gurbani
Enviado el: lunes, 28 de septiembre de 2020 17:43
Para: Luis M. Contreras 
CC: IETF ALTO 
Asunto: [alto] Interested in reviewing unified-props? And other drafts as well

Dear Luis: Are you still interested in reviewing unified-props?  If so, can you 
please let Jan and me know as soon as possible?  The draft needs an in-depth 
WGLC review by Oct. 9.

All: Since my posting asking for volunteers to review unified-props [1], I have 
received no offers.  Considering that we have performance-metrics draft and the 
path-vector draft that need to be reviewed for WGLC, the lack of review 
volunteers do not bode well.

One logical conclusion that can be drawn if we do not get any review offers is 
that the WG does not have the energy to finish existing work.  This begs the 
question on why recharter ALTO if we cannot meet the current deadlines.

A subset of you are organizing weekly meetings to further the work on drafts 
and re-chartering.  My advice would be that effort spent on those meetings 
should be redirected (or at least shared) with reviewing existing drafts so we 
can finish up the work and get ready for re-chartering.

[1] https://mailarchive.ietf.org/arch/msg/alto/cWi2YNk6odQ_hL-0oF9GRxKyYqs/

Cheers,

- vijay



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

Re: [alto] ALTO Meeting Info for May. 27, 2020

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all

I'm afraid It Will not possible for me to attend today. Maybe I can join at the 
very last parte

Apologies

Luis

Obtener Outlook para Android


From: alto-weekly-meet...@googlegroups.com 
 on behalf of Danny Alex Lachos Perez 

Sent: Tuesday, May 26, 2020 7:14:30 PM
To: IETF ALTO ; alto-weekly-meet...@googlegroups.com 

Subject: ALTO Meeting Info for May. 27, 2020

Dear all,

Just a friendly reminder that we will have our weekly meeting this Wednesday 
(May-27) at 9:00 am US ET.

Agenda*:

  *   WG documents status
  *   NAI Workshop

* If people have other agenda items, please feel free to post.

Bridge link: https://yale.zoom.us/my/yryang

Best regards,

Danny Lachos

--
You received this message because you are subscribed to the Google Groups 
"alto-weekly-meeting" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
alto-weekly-meeting+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/alto-weekly-meeting/CAEDarXKVqGGBwVQ2BLQ68K5RWWejCRvq_2A3qqc-yFxoHHyCyA%40mail.gmail.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

Re: [alto] ALTO Meeting Info for Mar. 25, 2020

[LUIS MIGUEL CONTRERAS MURILLO]

I will not be able to join today, my apologies

Luis

De: alto-weekly-meet...@googlegroups.com  
En nombre de Jensen Zhang
Enviado el: martes, 24 de marzo de 2020 17:55
Para: IETF ALTO ; alto-weekly-meet...@googlegroups.com
Asunto: ALTO Meeting Info for Mar. 25, 2020

Hi ALTOers,

Just a friendly reminder that we will have our weekly meeting this Wednesday 
(Mar-25) at 9:30 am US ET.

Agenda*:

  *   Progress on topics related to WG rechartering
  *   Potential topics for ANI workshop submission
* If people have other agenda items, please feel free to post.

Bridge link: https://yale.zoom.us/my/yryang

Best regards,
Jensen
--
You received this message because you are subscribed to the Google Groups 
"alto-weekly-meeting" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
alto-weekly-meeting+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/alto-weekly-meeting/CAAbpuyqsYxUTt8Tmdc7na8Z%3DUg-PQ8PR4kaG-pOBDwnfrY%2BQkQ%40mail.gmail.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

Re: [alto] ALTO Meeting Info for Dec. 18, 2019 [last meeting before Xmas break]

[LUIS MIGUEL CONTRERAS MURILLO]

I will not be able to attend today, apologies.

Obtener Outlook para Android

From: alto-weekly-meet...@googlegroups.com 
 on behalf of Danny Alex Lachos Perez 

Sent: Tuesday, December 17, 2019 5:27:15 PM
To: IETF ALTO ; alto-weekly-meet...@googlegroups.com 

Subject: ALTO Meeting Info for Dec. 18, 2019 [last meeting before Xmas break]

Dear all,

Just a friendly reminder that we will have one more weekly meeting this 
Wednesday before the Xmas break.

Agenda*:

  *   Discuss WG rechartering
  *   Updates on existing WG documents
  *   Plan for next side meeting/workshop

*If people have other agenda items, please feel free to post.

Date/time: Dec-18 at 9:30 am US ET.
Bridge link: https://yale.zoom.us/j/8423318713

Best regards,

Danny Lachos

--
You received this message because you are subscribed to the Google Groups 
"alto-weekly-meeting" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
alto-weekly-meeting+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/alto-weekly-meeting/CAEDarXLjGLbXdwrmR1P40Hx-dV4cTgL%3D%3D-8jj_bNG4mTkYrM4w%40mail.gmail.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

Re: [alto] ALTO meeting info for Oct. 30, 2019

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all

This week I’m attending a Conference, so it will not possible for me to attend 
the call.

Apologies for that

Best regards

Luis

De: alto-weekly-meet...@googlegroups.com  
En nombre de Danny Alex Lachos Perez
Enviado el: martes, 29 de octubre de 2019 18:03
Para: IETF ALTO ; alto-weekly-meet...@googlegroups.com
Asunto: ALTO meeting info for Oct. 30, 2019

Dear all,

Just a friendly reminder that we will have our weekly meeting this Wednesday 
(Oct-30) at 9:30 am US ET.

Agenda*:

  *   Planning for ALTO workshop (IETF106)
  *   Quick updates on existing WG documents
*If people have other agenda items, please feel free to post.

Bridge link: https://yale.zoom.us/j/8423318713

Best regards,

Danny Lachos
--
You received this message because you are subscribed to the Google Groups 
"alto-weekly-meeting" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
alto-weekly-meeting+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/alto-weekly-meeting/CAEDarXJStq%2BrGYAeoc%3DY%2BgXUmOHfUQRngongA2G5ZUHASnukBg%40mail.gmail.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

Re: [alto] [ALTO] Skip tomorrow's meeting (Jul. 31, 2019)

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all,

Ok for me to skip tomorrow’s call. By the way I enter into the vacation period, 
skipping ALTO calls up to September.

Best regards

Luis

De: alto-weekly-meet...@googlegroups.com  
En nombre de Danny Alex Lachos Perez
Enviado el: martes, 30 de julio de 2019 19:00
Para: IETF ALTO 
CC: alto-weekly-meet...@googlegroups.com
Asunto: [ALTO] Skip tomorrow's meeting (Jul. 31, 2019)

Dear ALTOers,

First, thanks to all of you for the contributions and excellent IETF105 ALTO 
meeting (great job!)
Given that we had the meeting last Thursday, how about we skip tomorrow's 
weekly meeting?

For the next week, we may then resume our discussions on existing documents 
(e.g., UP, PV, and FCI are calling for reviews) and next steps.

Best regards,

Danny Lachos
--
You received this message because you are subscribed to the Google Groups 
"alto-weekly-meeting" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
alto-weekly-meeting+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/alto-weekly-meeting/CAEDarXKa-A80wK_txAms%2B46ro6ik6sTo%3Di_4kXYYWxH7KdyaqA%40mail.gmail.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

Re: [alto] ALTO weekly meetings

[LUIS MIGUEL CONTRERAS MURILLO]

Dear all,

Unfortunately, I will not be able to join the regular meeting today since I’m 
on business trip. Join you next week.

Best regards

Luis

De: Danny Alex Lachos Perez 
Enviado el: martes, 2 de abril de 2019 16:05
Para: IETF ALTO 
CC: Akrit Mudvari (Yale) ; Avi Silberscatz (Yale) 
; Börje Ohlman (Ericsson) ; C. 
Xiong (Tencent) ; Christian Esteve (Unicamp) 
; Dawn Chan ; Dong Guo 
(PCL/Tongji) ; Farni Weaver (Sprint) ; 
Franck Le (IBM Watson) ; Gao Kai (SCU) ; 
Geng Li (Yale) ; Harvey Newman (Caltech) 
; Jan Seedorf ; Jensen 
Zhang (Tongji) ; Jia Wang (ATT) 
; Julien Maisonneuve (Nokia - FR/Paris-Saclay) 
; Kerim Gokarslan (Yale) 
; LUIS MIGUEL CONTRERAS MURILLO 
; Lyle Bertz (Sprint) 
; Mirja Kühlewind ; 
Nelson Zha (Tencent) ; Qiao Xiang (Yale) 
; Sabine Randriamasy (Nokia - FR/Paris-Saclay) 
; Shawn Lin (Tongji) 
; Shenshen Chen (Tongji/Yale) 
; Vijay Gurbani (Vail) ; X. 
Tony Wang (PCL/Tongji) ; Y. Grace Liu (Simons 
Foundation/Flatiron Institute) ; Y. Richard Yang 
(Yale) ; Yeon-sup Lim (IBM Watson) ; Yunfei 
Zhang (Tencent) 
Asunto: Re: ALTO weekly meetings

Hello all,

Just a friendly reminder that we will have our ALTO weekly meeting this 
Wednesday (Apr-03) at 9:30 am US ET.

Agenda*:

  *   Existing WG items (in particular, Unified Properties and FCI)

*If people have other agenda items, please feel free to post.

Bridge: https://yale.zoom.us/j/8423318713

Best regards,

Danny Lachos

On Thu, Mar 28, 2019 at 2:34 PM Y. Richard Yang 
mailto:y...@cs.yale.edu>> wrote:
Dear all,

Thanks a lot to those who attended the IETF ALTO session the day before 
yesterday (Tuesday) either remotely using Meetecho or in person in Prague. For 
those who did not attend, it was a wonderful session, in which we discussed 
both the progress of existing WG documents and 3 potential remaining work. The 
chairs and AD provided clear guidance and suggestions!

During the meeting, we mentioned the Wednesday weekly meetings started last 
year in which a team discusses both the existing WG documents and potential 
extensions.

The schedule from this point is planned as the following: we discuss existing 
documents and extensions in alternate weeks, and hence the plan for the next 4 
weeks is the following:

- Apr. 3: Existing documents; in particular, Unified Properties and FCI
- Apr. 10: Extensions (5G, and other use cases)
- Apr. 17: Existing documents, in particular, PV
- Apr. 24: Extensions (5G, and other use cases)

Danny is our meeting tsar; and Jensen the backup tsar.

It is not required that everyone attends each meeting, but any suggestions for 
topics are highly welcome. The meetings are open and feel free to join. To 
avoid spamming the alto@ietf mailing list, we will post meeting reminders for 
the first two meetings to alto@ietf and then will stop. If you want to receive 
later reminders, please let me (Danny or Jensen) know, and we will love to have 
you.

The meetings are always at 9:30 US ET (EU may change Daylight soon and we plan 
to stick to the US schedule for now).

The meetings use zoom to allow sharing of slides:
https://yale.zoom.us/j/8423318713
Cheers,
Y. Richard Yang
Professor of Computer Science



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

Re: [spring] draft-xu-mpls-sr-over-ip

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Loa

I'm not aware of any IPR that applies to this draft.

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

-Mensaje original-
De: spring  En nombre de Loa Andersson
Enviado el: jueves, 7 de junio de 2018 12:15
Para: m...@ietf.org
CC: spring@ietf.org; mpls-cha...@ietf.org; draft-xu-mpls-sr-over...@ietf.org
Asunto: [spring] draft-xu-mpls-sr-over-ip



Working Group,

We are currently preparing draft draft-xu-mpls-sr-over-ip for working
group adoption.

Part of this preparation is to do an IPR poll.

This mail is to start the IPR poll.

Are you aware of any IPR that applies to draft-xu-mpls-sr-over-ip?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

There are currently no IPR disclosures against draft-xu-mpls-sr-over-ip.

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR. *The response needs to be sent to the MPLS WG mailing list.* The
document will not advance to the next stage until a response has been
received from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any
IPR that has not yet been disclosed in conformance with IETF rules.

We have copied this mail to the SPRING wg mailing list for information.
If you receive this mail over the SPRING wg mailing list, and are aware
of IPRs that apply to the draft, please notify the MPLS wg list.


/Loa
  mpls wg co-chair
--


Loa Anderssonemail: l...@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting phone: +46 739 81 21 64

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring



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

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [OPSAWG] WG adoption poll for draft-wu-opsawg-service-model-explained-06

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Adrian,

Sorry for my late response. Thanks for the clarifications. They are fine to me.

Best regards

Luis


-Mensaje original-
De: Adrian Farrel [mailto:adr...@olddog.co.uk]
Enviado el: miércoles, 23 de agosto de 2017 17:28
Para: LUIS MIGUEL CONTRERAS MURILLO 
<luismiguel.contrerasmuri...@telefonica.com>; 'Tianran Zhou' 
<zhoutian...@huawei.com>; opsawg@ietf.org
CC: opsawg-cha...@ietf.org
Asunto: RE: [OPSAWG] WG adoption poll for 
draft-wu-opsawg-service-model-explained-06

Hey Luis,

As we are updating the draft for last call comment, here are responses to your 
comments.

> *Specific comments*
>
> - There are several sentences along the document trying to define the
> scope of service model in the context of IETF. These are: (1) in Terms
> and Concepts,
for
> Service, "... A service in the context of this document (sometimes
> called a Network Service) is some form of connectivity between
> customer sites and the Internet, or between customer sites across the
> network operator's network and across the Internet"; (2) section 5,
> first bullet, "The services we are
discussing are
> services provided by network operators to customers ... network
> operators may offer value-added services as well as network connection
> services to their customers.";  (3) section 6.4, "The IETF's work on
> service models is typically smaller offering a simple, self-contained service 
> YANG module".
> Since in the abstract it is stated that "This document briefly sets
> out the
scope of
> and purpose of an IETF service model", probably the best would be to
> include
at
> the very beginning a clear sentence with such definition, in order to
> focus
the
> reader.

OK. That is easy to add.

  In summary, a service model is a formal representation of the data 
elements
  that describe a network service as that service is described to or 
requested
  by a customer of a network operator.  Details included in the service 
model
  include a description of the service as experienced by the customer, but 
not
  features of how that service is delivered or realized by the service 
provider.

> - In abstract: "... details of how network protocols and devices are
engineered to
> deliver a service are captured in other models that are not exposed
> through
the
> Customer-Provider Interface" <-- Thinking on recursiveness, the
> Customer- Provide Interface can require low-level details or models.
> In other words,
when a
> Network Operator is Customer of another Network Operator, what kind of
> interface would you consider for that relationship?

For me, recursion does not add detail. So, a network operator that engages with 
another network operator as a customer could do so exactly using the service 
model.

If the relationship is internal to a commercial organisation then it is 
possible that the interface will be more transparent.

It is also true that if the recursion happens lower down (e.g., at the service 
delivery interface) then more details are exposed.

I don't believe that any of this has direct bearing on this document, but I can 
see that there may be space for more architectural debate about how SDN systems 
are constructed. MEF, ETSI, and TMF seem to be having this sort of discussion.

> - Figure 2: in contrast with Figure 3, where would be positioned here
> the
Service
> Delivery models? Should it be assumed a collapse of functionality in
> the Orchestrator of Fig. 2 including both Service and Network
> Orchestrator? Would be those models internal? Maybe it could be convenient to 
> reflect also in Fig.
2
> both Service Delivery and Network Configuration models, for consistency.

I think that is exactly the point. The "traditional" SDN approach shown in 
Figure 2 makes it hard to place these different models in context, so we 
introduce an extended view in Figure 3.

> - In section 4, below Fig. 2: "This means that the service request
> must be
mapped
> to the orchestrator's view, and this mapping may include a choice of
> which networks and technologies to use depending on which service
> features have been requested." < -- Such mapping is performed by the
> Orchestrator itself, right? So maybe the sentence can be rephrased
> (e.g., ... the service request
must
> be mapped by the orchestrator ...).

Yeah. OK.

> - Figure 3. The Customer Service model in segment (a) would be
> probably something else than a connectivity/transport service, even
> though parts of
such
> service request are out of scope of IETF. I mean, e.g. a Network
> Service Descriptor in NFV. So the Service Orchestrator purpose can be
> broader than
what
> is the scope of IETF. This can be maybe clarified.

It is true that there is a broader architectural picture sitting beh

[Tccc] Call for Participation (Update): International Workshop on Cross-Stratum Optimization for Cloud Computing and Distributed Networked Applications

[LUIS MIGUEL CONTRERAS MURILLO]

*Apologies if you receive duplicate copies of this message*

* Final Programme update*

--

Call for Participation

International Workshop on Cross-Stratum Optimization for Cloud Computing and 
Distributed Networked Applications

July 13, 2012 - Leganés, Madrid, Spain

http://cccso.net/ or http://www.cccso.net/ Co-located with 10th IEEE 
International Symposium on Parallel and Distributed Processing with 
Applications (ISPA 2012) 

http://www.arcos.inf.uc3m.es/ispa12/index.shtml



- Final Programme -



Session I (8:30-11:00) - Chair: Andrea Fumagalli, The University of Texas at 
Dallas

.- Cross Stratum Optimization (CSO) Enabled PCE Architecture, Dhruv Dhody and 
Young Lee

.- Overlay Consolidation of ISP-Provided Preferences, Raul Landa, Eleni 
Mykoniati, David Griffin, Miguel Rio, Nico Schwan and Ivica Rimac

.- Delay Performance of Resilient Cloud Services over Networks, Isil Burcu 
Barla, Dominic A. Schupke and Georg Carle

.- Building Network-Aware Composite Services With the GEMBus Framework, Pedro 
Martinez-Julia, Diego R. Lopez and Antonio F. Skarmeta

.- An ILP formulation for CSO Data Center Selection Joint Optimization, Marco 
Tacca, Miguel Razo-Razo, Wanjun Huang, Andrea Fumagalli and Ning So

.- Towards Cross Stratum SLA Management with the GEYSERS Architecture, Philip 
Robinson, Alexandru-Florian Antonescu, Luis M. Contreras, Jose Aznar, Fabienne 
Anhalt and Joan A. García-Espín.



Session II (11:30-13:00) - Chair: Young Lee, Huawei

.- Keynote Speaker:  Víctor López, Telefónica I+D Cross Stratum Optimization 
as a key technology for cloud-ready networks

.- Cross-Stratum Optimization aware Provisioning Algorithm for Cloud Data 
Centers, Shahnaza Tursunova, Taeho Lee, Nodir Kodirov and Taesang Choi

Demonstrations:

- Demo 1: Optimizing Network and Data Center resources during cloud 
balancing, by Huawei

- Demo 2: A Simulation Engine for Cross Stratum Optimization, by The 
University of Texas at Dallas

- Demo 3: Demonstration of OaaS with GLB Strategy, by the Beijing University 
of Posts and Telecommunications (BUPT)





Best regards,



Luis


_
Luis M. Contreras
Technology / Global CTO Telefónica
Efficiency Projects / Telefónica I+D

Don Ramón de la Cruz 82-84
28006 Madrid
España / Spain

l...@tid.es



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
___
IEEE Communications Society Tech. Committee on Computer Communications
(TCCC) - for discussions on computer networking and communication.
Tccc@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/tccc

[Tccc] CfP International Workshop on Cross-Stratum Optimization for Cloud Computing and Distributed Networked Applications

[LUIS MIGUEL CONTRERAS MURILLO]

[Apologies if you receive multiple copies of this message]

After receiving several request the organizers have decided to extend the 
deadline.
Authors are encouraged to register their paper today by indicating the title 
and a tentative abstract.
The full paper can be submitted at a later time, but on or before March 2nd

Deadline Extension
Call for Papers for the International Workshop on Cross-Stratum Optimization 
for Cloud Computing and Distributed Networked Applications
http://cccso.net/ or http://www.cccso.net/

Co-located with the 10th IEEE International Symposium on Parallel and 
Distributed Processing with Applications, ISPA 2012 
http://www.arcos.inf.uc3m.es/ispa12/index.shtml
July 10-13, 2012

Leganes, Madrid, Spain

Aims and Scope
=
The current lack of interaction between networked applications and the 
underlying network during service provisioning can cause inefficiencies in the 
use of network resources and can negatively impact the quality received by the 
final consumers of those applications.
Typical networked applications are offered through Information Technology (IT) 
resources (such as computing and storage facilities) residing in data centers. 
Data centers then provide the physical and virtual infrastructure in which 
applications and services are provided. Since the data centers are usually 
distributed geographically around a network, many decisions made in the control 
and management of application services, such as where to instantiate another 
service instance, or which data center out of several is assigned to a new 
customer, can have a significant impact on the state of the network. In the 
same way, the capabilities and state of the network can have a major impact on 
application performance.
Cross-stratum optimization (CSO) is defined as the combined optimization of 
both the IT data center and the network components of an application that aims 
to provide joint resource optimization, responsiveness to quickly changing 
demands from/to application to/from network, enhanced service resilience using 
cooperative recovery techniques, and quality of experience assurance by a 
better use of existing network and application resources, among others.
The CSO involves the overall optimization of application layer (IT) and network 
resources by envisioning next generation architecture for interactions and 
exchanges between the two layers to improve service continuity, performance 
guarantees, scalability and manageability. The goal of this workshop is to 
promote the research interest on the optimal integration of application and 
network resources.
This workshop aims to explore the challenges and issues faced by cloud 
computing and data center integration with networks. Among the key areas of 
investigation to be discussed in the workshop are as follows:
.- Application/network integration architectures and subsystems
.- Use cases, business models and requirements for application/network 
integration
.- Control/management issues for application/network integration
.- Network virtualization and its impact for application/network integration
.- Network-aware application/cloud computing
.- Flexible and scalable networking solutions for distributed Data Centers
.- Joint application/network reliability and security
.- Experimental/trial experience
.- Scalability
.- Joint/shared performance and fault monitoring
.- Multi-domain issues

Important Dates
===
Extended Submission Deadline: 02 March 2012 (*extended final* deadline)
Paper Acceptance Notification: 30 March 2012
Camera-ready Paper Submissions: 13 April 2012
Tentative workshop day: 10 July 2012 (to be confirmed)

Venue
==
Universidad Carlos III de Madrid, Leganes, Madrid, Spain

Submision guidelines

Target papers should describe original and unpublished work. All papers must be 
submitted in PDF format. Authors should submit full papers of up to 6 pages, 
following strictly the IEEE Computer Society Proceedings Manuscript style 
(available at http://www.computer.org/portal/web/cscps/formatting), using 
two-column, single-space format, with 10-point font size. Figures and 
references must be included in the 6 pages.
The submission process will be done online by using EasyChair submission system:
http://www.easychair.org/conferences/?conf=ispa2012
choosing this workshop among the various workshops held in conjunction with 
ISPA-2012
Submissions received after deadline, exceeding length limit, or not following 
the specified format will not be considered.
The proceedings will be published by the IEEE in the same volume as the main 
conference and will be made online through the IEEE Xplore.

Technical Program Committee
===
Richard Alimi (Google, USA)
Greg Bernstein (Grotto Networking, USA)
TaeSang Choi (ETRI, Korea)
Nicola Ciulli (Nextworks, Italy)
Oscar Gonzalez de Dios (Telefónica I+D, Spain)
Volker Hilt (Bell Labs, USA)
Giada Landi (Nextworks, Italy)
Dan 

[alto] CfP International Workshop on Cross-Stratum Optimization for Cloud Computing and Distributed Networked Applications

[LUIS MIGUEL CONTRERAS MURILLO]

Dear colleagues,

I forward you the following Call for Papers because IMHO it is aligned with the 
interests of this community.

I think this could be a good place where disseminate original work part of, or 
based on, the work being carried here.

Sorry for any inconvenience,

Thanks, best regards,

Luis

[Apologies if you receive multiple copies of this message]

Reminder
Call for Papers for the International Workshop on Cross-Stratum Optimization 
for Cloud Computing and Distributed Networked Applications
http://cccso.net/ or http://www.cccso.net/

Co-located with the 10th IEEE International Symposium on Parallel and 
Distributed Processing with Applications, ISPA 2012 
http://www.arcos.inf.uc3m.es/ispa12/index.shtml
July 10-13, 2012

Leganes, Madrid, Spain

Aims and Scope
=
The current lack of interaction between networked applications and the 
underlying network during service provisioning can cause inefficiencies in the 
use of network resources and can negatively impact the quality received by the 
final consumers of those applications.
Typical networked applications are offered through Information Technology (IT) 
resources (such as computing and storage facilities) residing in data centers. 
Data centers then provide the physical and virtual infrastructure in which 
applications and services are provided. Since the data centers are usually 
distributed geographically around a network, many decisions made in the control 
and management of application services, such as where to instantiate another 
service instance, or which data center out of several is assigned to a new 
customer, can have a significant impact on the state of the network. In the 
same way, the capabilities and state of the network can have a major impact on 
application performance.
Cross-stratum optimization (CSO) is defined as the combined optimization of 
both the IT data center and the network components of an application that aims 
to provide joint resource optimization, responsiveness to quickly changing 
demands from/to application to/from network, enhanced service resilience using 
cooperative recovery techniques, and quality of experience assurance by a 
better use of existing network and application resources, among others.
The CSO involves the overall optimization of application layer (IT) and network 
resources by envisioning next generation architecture for interactions and 
exchanges between the two layers to improve service continuity, performance 
guarantees, scalability and manageability. The goal of this workshop is to 
promote the research interest on the optimal integration of application and 
network resources.
This workshop aims to explore the challenges and issues faced by cloud 
computing and data center integration with networks. Among the key areas of 
investigation to be discussed in the workshop are as follows:
.- Application/network integration architectures and subsystems
.- Use cases, business models and requirements for application/network 
integration
.- Control/management issues for application/network integration
.- Network virtualization and its impact for application/network integration
.- Network-aware application/cloud computing
.- Flexible and scalable networking solutions for distributed Data Centers
.- Joint application/network reliability and security
.- Experimental/trial experience
.- Scalability
.- Joint/shared performance and fault monitoring
.- Multi-domain issues

Important Dates
===
Extended Submission Deadline: 17 February 2012 (*firm* deadline)
Paper Acceptance Notification: 30 March 2012
Camera-ready Paper Submissions: 13 April 2012
Tentative workshop day: 10 July 2012 (to be confirmed)

Venue
==
Universidad Carlos III de Madrid, Leganes, Madrid, Spain

Submision guidelines

Target papers should describe original and unpublished work. All papers must be 
submitted in PDF format. Authors should submit full papers of up to 6 pages, 
following strictly the IEEE Computer Society Proceedings Manuscript style 
(available at http://www.computer.org/portal/web/cscps/formatting), using 
two-column, single-space format, with 10-point font size. Figures and 
references must be included in the 6 pages.
The submission process will be done online by using EasyChair submission system:
http://www.easychair.org/conferences/?conf=ispa2012
choosing this workshop among the various workshops held in conjunction with 
ISPA-2012
Submissions received after deadline, exceeding length limit, or not following 
the specified format will not be considered.
The proceedings will be published by the IEEE in the same volume as the main 
conference and will be made online through the IEEE Xplore.

Technical Program Committee
===
Richard Alimi (Google, USA)
Greg Bernstein (Grotto Networking, USA)
TaeSang Choi (ETRI, Korea)
Nicola Ciulli (Nextworks, Italy)
Oscar Gonzalez de Dios (Telefónica I+D, Spain)
Volker Hilt (Bell Labs, USA)
Giada Landi 

[Tccc] CfP International Workshop on Cross-Stratum Optimization for Cloud Computing and Distributed Networked Applications

[LUIS MIGUEL CONTRERAS MURILLO]

[Apologies if you receive multiple copies of this message]

Reminder
Call for Papers for the International Workshop on Cross-Stratum Optimization 
for Cloud Computing and Distributed Networked Applications
http://cccso.net/ or http://www.cccso.net/

Co-located with the 10th IEEE International Symposium on Parallel and 
Distributed Processing with Applications, ISPA 2012 
http://www.arcos.inf.uc3m.es/ispa12/index.shtml
July 10-13, 2012

Leganes, Madrid, Spain

Aims and Scope
=
The current lack of interaction between networked applications and the 
underlying network during service provisioning can cause inefficiencies in the 
use of network resources and can negatively impact the quality received by the 
final consumers of those applications.
Typical networked applications are offered through Information Technology (IT) 
resources (such as computing and storage facilities) residing in data centers. 
Data centers then provide the physical and virtual infrastructure in which 
applications and services are provided. Since the data centers are usually 
distributed geographically around a network, many decisions made in the control 
and management of application services, such as where to instantiate another 
service instance, or which data center out of several is assigned to a new 
customer, can have a significant impact on the state of the network. In the 
same way, the capabilities and state of the network can have a major impact on 
application performance.
Cross-stratum optimization (CSO) is defined as the combined optimization of 
both the IT data center and the network components of an application that aims 
to provide joint resource optimization, responsiveness to quickly changing 
demands from/to application to/from network, enhanced service resilience using 
cooperative recovery techniques, and quality of experience assurance by a 
better use of existing network and application resources, among others.
The CSO involves the overall optimization of application layer (IT) and network 
resources by envisioning next generation architecture for interactions and 
exchanges between the two layers to improve service continuity, performance 
guarantees, scalability and manageability. The goal of this workshop is to 
promote the research interest on the optimal integration of application and 
network resources.
This workshop aims to explore the challenges and issues faced by cloud 
computing and data center integration with networks. Among the key areas of 
investigation to be discussed in the workshop are as follows:
.- Application/network integration architectures and subsystems
.- Use cases, business models and requirements for application/network 
integration
.- Control/management issues for application/network integration
.- Network virtualization and its impact for application/network integration
.- Network-aware application/cloud computing
.- Flexible and scalable networking solutions for distributed Data Centers
.- Joint application/network reliability and security
.- Experimental/trial experience
.- Scalability
.- Joint/shared performance and fault monitoring
.- Multi-domain issues

Important Dates
===
Extended Submission Deadline: 17 February 2012 (*firm* deadline)
Paper Acceptance Notification: 30 March 2012
Camera-ready Paper Submissions: 13 April 2012
Tentative workshop day: 10 July 2012 (to be confirmed)

Venue
==
Universidad Carlos III de Madrid, Leganes, Madrid, Spain

Submision guidelines

Target papers should describe original and unpublished work. All papers must be 
submitted in PDF format. Authors should submit full papers of up to 6 pages, 
following strictly the IEEE Computer Society Proceedings Manuscript style 
(available at http://www.computer.org/portal/web/cscps/formatting), using 
two-column, single-space format, with 10-point font size. Figures and 
references must be included in the 6 pages.
The submission process will be done online by using EasyChair submission system:
http://www.easychair.org/conferences/?conf=ispa2012
choosing this workshop among the various workshops held in conjunction with 
ISPA-2012
Submissions received after deadline, exceeding length limit, or not following 
the specified format will not be considered.
The proceedings will be published by the IEEE in the same volume as the main 
conference and will be made online through the IEEE Xplore.

Technical Program Committee
===
Richard Alimi (Google, USA)
Greg Bernstein (Grotto Networking, USA)
TaeSang Choi (ETRI, Korea)
Nicola Ciulli (Nextworks, Italy)
Oscar Gonzalez de Dios (Telefónica I+D, Spain)
Volker Hilt (Bell Labs, USA)
Giada Landi (Nextworks, Italy)
Dan Li (Huawei, China)
Vishwas Manral (HP, USA)
Thomas D. Nadeau (CA Technologies, USA)
Kohei Shiomoto (NTT, Japan)
Ning So (Verizon, USA)
Hui Yang (Beijing University Post and Telecommunication (BUPT), China)
Yang Richard Yang (Yale University, USA)

Workshop Organizing Committee

[Tccc] CfP International Workshop on Cross-Stratum Optimization for Cloud Computing and Distributed Networked Applications

[LUIS MIGUEL CONTRERAS MURILLO]

[Apologies if you receive multiple copies of this message]

First Call for Papers for the International Workshop on Cross-Stratum 
Optimization for Cloud Computing and Distributed Networked Applications
http://cccso.net/

Co-located with the 10th IEEE International Symposium on Parallel and 
Distributed Processing with Applications, ISPA 2012
http://www.arcos.inf.uc3m.es/ispa12/index.shtml
July 10-13, 2012
Leganes, Madrid, Spain

Aims and Scope
=
The current lack of interaction between networked applications and the 
underlying network during service provisioning cause inefficiencies on the use 
of network resources which can negatively impact the quality expectations of 
the final consumers of those applications.

Typical networked applications are offered through Information Technology (IT) 
resources (as computing and storage facilities) residing in data centers. Data 
centers then provide the physical and virtual infrastructure in which 
applications and services are provided. Since the data centers are usually 
distributed geographically around a network, many decisions made in the control 
and management of application services, such as where to instantiate another 
service instance, or which data center out of several is assigned to a new 
customer, can have a significant impact on the state of the network. In the 
same way, the capabilities and state of the network can have a major impact on 
application performance.

Cross-stratum optimization (CSO) is referred to the combined optimization of 
both the application and the network components that aims to provide joint 
resource optimization, responsiveness to quickly changing demands from/to 
application to/from network, enhanced service resilience using cooperative 
recovery techniques, and quality of experience assurance by a better use of 
existing network and application resources, among others.

The CSO involves the overall optimization of application layer and network 
resources by envisioning next generation architecture for interactions and 
exchanges between the two layers to improve service continuity, performance 
guarantees, scalability and manageability. The goal of this workshop is to 
promote the research interest on the optimal integration of application and 
network resources.

This workshop aims to explore the challenges and issues faced by cloud 
computing and data center integration with networks. Among the key areas of 
investigation to be discussed in the workshop are as follows:

.- Application/network integration architectures and subsystems
.- Use cases, business models and requirements for application/network 
integration
.- Control/management issues for application/network integration
.- Network virtualization and its impact for application/network integration
.- Network-aware application/cloud computing
.- Flexible and scalable networking solutions for distributed Data Centers
.- Joint application/network reliability and security
.- Experimental/trial experience
.- Scalability
.- Joint/shared performance and fault monitoring
.- Multi-domain issues

Important Dates
===
Paper Submission Deadline: 03 February 2012
Paper Acceptance Notification: 30 March 2012
Camera-ready Paper Submissions: 13 April 2012
Tentative workshop day: 10 July 2012 (to be confirmed)

Venue
=
Universidad Carlos III de Madrid, Leganes, Spain

Submision guidelines

Target papers should describe original and unpublished work. The submission 
process will be done online by using EasyChair submission system:
http://www.easychair.org/conferences/?conf=ispa2012
choosing this workshop among the various workshops held in conjunction with 
ISPA-2012
Details on the paper format and length will be provided soon.

Technical Program Committee
===
Richard Alimi (Google, USA)
Greg Bernstein (Grotto Networking, USA)
TaeSang Choi (ETRI, Korea)
Nicola Ciulli (Nextworks, Italy)
Oscar Gonzalez de Dios (Telefónica I+D, Spain)
Volker Hilt (Bell Labs, USA)
Giada Landi (Nextworks, Italy)
Dan Li (Huawei, China)
Thomas D. Nadeau (CA Technologies, USA)
Kohei Shiomoto (NTT, Japan)
Ning So (Verizon, USA)
Hui Yang (Beijing University Post and Telecommunication (BUPT), China)
Yang Richard Yang (Yale University, USA)

Workshop Organizing Committee
=
Young Lee, Huawei Technologies (leeyoung (at) huawei.com)
Luis M. Contreras, Telefónica I+D (lmcm (at) tid.es)
Andrea Fumagalli, The University of Texas at Dallas (andreaf (at) utdallas.edu)



___
Luis M. Contreras
Telefónica I+D
l...@tid.es



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx