Re: [altoext] i2aex BOF

Hi Diego,

One minor comment in line, just for clarification.

-----Mensaje original-----
De: altoext-bounces@ietf.org [mailto:altoext-bounces@ietf.org] En nombre de DIEGO LOPEZ GARCIA
Enviado el: domingo, 08 de abril de 2012 16:14
Para: Greg Bernstein
CC: altoext@ietf.org
Asunto: Re: [altoext] i2aex BOF - Large Bandwidth Use Case

On 4 Apr 2012, at 19:34 , Greg Bernstein wrote:
> It is very interesting to compare the different notions of "Network as a Service" (NaaS) and see what type of additional information various NaaS notions would require from the network.
>
> . . .
>
> It seems that the graph based I2AEX extensions that we like would apply to (a) and (d), and to all casesl if traffic engineering (layer 2 or 3) is desired.  Comments? Other examples that we should look at? I'm working to formalize the graph stuff we showed at the BoF in proper ALTO protocol form and should have a draft in a few more weeks.

My take is that the NaaS proposals are tailored to the kind of user communities they address. As far as I understand them, both Mantychore and GEYSERS intend to provide additional tools to network engineers themselves, and therefore expose a more detailed network abstraction. Two remarks that come to my mind is that I definitely have to look into Quantum in more detail, and the interesting fact that GEYSERS is intended to have bidirectional information flows (describing computing resources as well).

[Luis>>] It would be more appropriate to talk about bidimensional information flows, rather than bidirectional, in the sense that both IT and network resources are considered by the network control plane. There is also a service provisioning case, called full-anycast in GEYSERS, where the network control plane proposes the IT endpoint to be connected, performing that bidirectional communication you mention, but essentially we could say that GEYSERS is based unidirectional flows towards the network control plane, in order to implement the appropriate path calculation between end points.

The i2aex interfaces shall be able to deal to these different level of abstraction and with the different abstract models that different use cases rely on. For example, in the DC case a L2 abstraction seems the most appropriate (hiding overlay details), while a CDN will likely want to know about L3 topology details (albeit in a rather management rather than physical manner).

And I'm looking forward to seeing your formalization proposal.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego@tid.es
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

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
_______________________________________________
altoext mailing list
altoext@ietf.org
https://www.ietf.org/mailman/listinfo/altoext

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