Subject: Re: [altoext] i2aex BOF - Large Bandwidth Use Case

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 02 Apr 2012 11:37:13 +0200

Hi Greg,

On 29 Mar 2012, at 20:12 , Greg Bernstein wrote:
> The separation between an interface such as an extended alto that could give an application more information about the underlying "high bandwidth" network in a suitably abstract form, and an interface to set up the "express lanes". Seems analogous to what we did in GMPLS. In GMPLS the routing protocols are used to give detailed network topology and properties, while a separate signaling protocol (RSVP-TE) is used to actually set up those connections. One can and usually does lag the other as we extend GMPLS to deal with new technologies.

And using an extended ALTO plus the request interface would provide an
additional management plane, with suitable abstractions according to the
type of application and the level of control and information the network
operator is willing to provide in each case.

> In looking at the research projects you cited I noticed the following:
> (a) Geysers -- has something called the Enhanced Network Connectivity Service which sounds similar to what we might be talking about. I didn't see anymore details though. Anyone know of exactly where to find documentation (these are large multifaceted projects and a bit hard to sift through) . Note that they build the network side of their system around and extended GMPLS and PCE. Which reinforces what we said in our draft about GMPLS and PCE being "enabling technologies".

Indeed. For documents related to what matters in this discussion, I'd
recommend the description of what is called LICL (Logical Infrastructure
Composition Layer, http://www.geysers.eu/images/stories/deliverables/geysers-deliverable_3.1.pdf)

A more condensed description will be soon available
at https://tnc2012.terena.org/core/presentation/58 as part of a GEYSERS
presentation in the TNC2012 conference.

> (b) GEMBus -- I saw a presentation of yours at the SOA layer, but couldn't find a document relating to application/network interfaces.

GEMBus is more oriented to the core services enabling these (and other)
interfaces, like a service registry and security mechanisms. So GEMBus could
be applicable here more as a supporting framework than as a direct model
for net/app interfaces. The most recent update on GEMBus is available at
http://www.geant.net/Media_Centre/Media_Library/Media%20Library/GN3-12-003_Composable_Network_Services%20DJ3_3_3_v1.0.pdf

I know the team is working in what they call a cookbook for GEMBus. I can
update you when it becomes available.

> (c) MantyChore -- They have a neat logo for OpenNaas (Network as a service) but no documentation that I could find yet. But it sounds like they are trying to bring optical, IP, and compute infrastructure together for research networks.

The demonstrators of the project will run on research networks, but is our
intention to explore its application in more general case. OpenNaas is
available as part of the Mantychore software releases (http://jira.i2cat.net:8090/display/MANTECH/Home), though it is right that
documentation is not its strongest point.

There is going to be a workshop on Mantychore during the next TNC as well
(https://tnc2012.terena.org/core/event/7)

> Hmm, with so much activity could be ripe for some type of standardization...  Or at least we could try to bring folks together to talk…

That's precisely the point! I'm trying to make this alignment to happen, as
I am or have been somehow involved in the three projects, and I'd like to see
them contribute to progressing standards in this are.

> You also commented on network management and reference the nice overview document  http://tools.ietf.org/html/draft-ietf-opsawg-management-stds-03.  The control plane, e.g. GMPLS, does not offer the full functionality of the management plane. The management plane has always been able to obtain more information and control more aspects of a network than the control plane. In the control plane we perform a few limited functions (topology discovery and resource status via link state routing, cross connect setup via RSVP-TE signaling).  Though we do like to thing that we do these better (faster, more     interoperable, more resilient, etc...)
>
> We also make abstractions in the control plane, for example in modeling SONET/SDH in GMPLS we "smoosh" the physical, regenerator section, and line section layers together since they are not "switching layers", but they are very important for network monitoring and SLA enforcement.

And that brings me back to the idea of a management plane that can provide
adapted views, based on the rights of the requester and the policy of the
operator.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: [email-masked]
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

---

From: Greg Bernstein <[email-masked]>
Date: Wed, 04 Apr 2012 10:34:36 -0700

Once again Diego, great pointers, and more fuel for thought.

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.

A rough summary from this perspective might be:

(a) GEYSERS -- they virtualize optical network elements such as OXCs, 
ROADMS, and optical links. They do not hide the fact that these are 
"optical" links and users would need to know how to perform RWA (routing 
and wavelength assignment). This seemed quite strange to me at first, 
then I remembered that this is an NREN project so the users want/need 
limited control capabilities over the optical layer.

(b) MantyChore -- "Mantychore Project: OpenNaaS, a toolkit for IP 
Networks as a Service". It looks like they are controlling "logical 
switches" and "logical routers". This is explained a bit more in 
http://jira.i2cat.net:8090/display/MANTECH/Project+Overview. Once again 
part of an NREN, gives control of virtualized layer 2 and 3 networks. It 
seems that explicit traffic engineering would come as they tie this in 
with GEYSERS.

(c) OpenStack - Quantum Project: 
Fromhttp://wiki.openstack.org/QuantumOverview /Quantum is a "virtual 
network service" that aims to provide a powerful API to define the 
network connectivity between "interface" devices implemented by other 
OpenStack services. --snip-- To start, Quantum is focused on providing 
L2 connectivity between "interfaces". However, the Quantum API will be 
extensible, allowing plugins to introduce new logical network 
abstractions, for example, to provide more advanced security or QoS 
policies. Extensions provide an avenue for innovation by allowing new 
functionality to be exposed. --snip--/  The V1.0 API contains interfaces 
for CRUD operations on L2 networks (VLANs), VLAN ports, and vNICs. 
Plugins exist for open source, e.g., Open vSwitch, as well as vendor 
specific software/hardware. Work has started on L3 network abstractions 
(IP subnets, routing tables). Note that there is a related but separate 
OpenStack project that deals with IP address management.

(d) Our High Bandwidth ALTO use cases: We were thinking of a "traffic 
engineered service" aimed at either layer 2 or layer 3 users. For 
simplicity to the application layer we were thinking of only exposing a 
single layer and hiding all the lower layer details, in particular the 
optical layer and method of implementing the "express lanes". However we 
would did want to show bandwidth and QoS related measures (e.g., 
latency, reliability, etc...).

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.

Best Regards

Greg B.

On 4/2/2012 2:37 AM, DIEGO LOPEZ GARCIA wrote:
> _______________________________________________
> altoext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/altoext
>
>

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Sun, 08 Apr 2012 16:14:24 +0200

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).

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,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 10 Apr 2012 10:00:40 +0200

Hi Greg,

Just a minor clarification about GEYSERS.  It is not actually focused on NREN; it really targets network operators, not only traditional ones, but facilitating new roles defining different interacting actors: Physical Infrastructure Providers (PIPs), Virtual Infrastructure Providers (VIPs), Virtual Infrastructure Operators (VIOs), etc.

All this roles, actors and interactions are well documented and available on public deliverables that can be downloaded from the project website (www.geysers.eu<http://www.geysers.eu>). Let me know if you want further information or clarification.

Best regards,

Luis

De: [email-masked] [mailto:[email-masked]] En nombre de Greg Bernstein
Enviado el: miércoles, 04 de abril de 2012 19:35
Para: [email-masked]
Asunto: Re: [altoext] i2aex BOF - Large Bandwidth Use Case

(a) GEYSERS -- they virtualize optical network elements such as OXCs, ROADMS, and optical links. They do not hide the fact that these are "optical" links and users would need to know how to perform RWA (routing and wavelength assignment). This seemed quite strange to me at first, then I remembered that this is an NREN project so the users want/need limited control capabilities over the optical layer.

(b) MantyChore -- "Mantychore Project: OpenNaaS, a toolkit for IP Networks as a Service". It looks like they are controlling "logical switches" and "logical routers". This is explained a bit more in http://jira.i2cat.net:8090/display/MANTECH/Project+Overview. Once again part of an NREN, gives control of virtualized layer 2 and 3 networks. It seems that explicit traffic engineering would come as they tie this in with GEYSERS.

(c) OpenStack - Quantum Project: From http://wiki.openstack.org/QuantumOverview Quantum is a "virtual network service" that aims to provide a powerful API to define the network connectivity between "interface" devices implemented by other OpenStack services. --snip-- To start, Quantum is focused on providing L2 connectivity between "interfaces". However, the Quantum API will be extensible, allowing plugins to introduce new logical network abstractions, for example, to provide more advanced security or QoS policies. Extensions provide an avenue for innovation by allowing new functionality to be exposed. --snip--  The V1.0 API contains interfaces for CRUD operations on L2 networks (VLANs), VLAN ports, and vNICs. Plugins exist for open source, e.g., Open vSwitch, as well as vendor specific software/hardware. Work has started on L3 network abstractions (IP subnets, routing tables). Note that there is a related but separate OpenStack project that deals with IP address management.

(d) Our High Bandwidth ALTO use cases: We were thinking of a "traffic engineered service" aimed at either layer 2 or layer 3 users. For simplicity to the application layer we were thinking of only exposing a single layer and hiding all the lower layer details, in particular the optical layer and method of implementing the "express lanes". However we would did want to show bandwidth and QoS related measures (e.g., latency, reliability, etc...).

Best Regards

Greg B.

Hi Greg,

Hmm, with so much activity could be ripe for some type of standardization...  Or at least we could try to bring folks together to talk...

operator.

Be goode,

--

Dr Diego R. Lopez

Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>

Tel:    +34 913 129 041

Mobile: +34 682 051 091

altoext mailing list

[email-masked]<mailto:[email-masked]>

--

________________________________
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

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 10 Apr 2012 10:54:40 +0200

Hi Diego,

One minor comment in line, just for clarification.

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

> 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…

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).

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/altoext