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

DIEGO LOPEZ GARCIA <diego@tid.es> Mon, 02 April 2012 09:37 UTC

Return-Path: <diego@tid.es>
X-Original-To: altoext@ietfa.amsl.com
Delivered-To: altoext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614C021F8897 for <altoext@ietfa.amsl.com>; Mon, 2 Apr 2012 02:37:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, WEIRD_PORT=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUQdu11nLYm5 for <altoext@ietfa.amsl.com>; Mon, 2 Apr 2012 02:37:18 -0700 (PDT)
Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 97D7221F88A9 for <altoext@ietf.org>; Mon, 2 Apr 2012 02:37:17 -0700 (PDT)
Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M1U00HP9IQ012@tid.hi.inet> for altoext@ietf.org; Mon, 02 Apr 2012 11:37:15 +0200 (MEST)
Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 76.54.03017.B43797F4; Mon, 02 Apr 2012 11:37:15 +0200 (CEST)
Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M1U00HPCIQ212@tid.hi.inet> for altoext@ietf.org; Mon, 02 Apr 2012 11:37:15 +0200 (MEST)
Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Mon, 02 Apr 2012 11:37:14 +0200
Date: Mon, 02 Apr 2012 11:37:13 +0200
From: DIEGO LOPEZ GARCIA <diego@tid.es>
In-reply-to: <4F74A608.4060303@grotto-networking.com>
To: Greg Bernstein <gregb@grotto-networking.com>
Message-id: <0A4496B5-1F35-4DE9-BA20-6431F880A1D4@tid.es>
MIME-version: 1.0
Content-type: text/plain; charset="Windows-1252"
Content-language: en-US
Content-transfer-encoding: quoted-printable
Accept-Language: en-US
Thread-topic: [altoext] i2aex BOF - Large Bandwidth Use Case
Thread-index: Ac0QtC+a9hppeLENSeedZb3NUhCWsQ==
acceptlanguage: en-US
X-AuditID: 0a5f4068-b7f0c6d000000bc9-4f-4f79734bed1b
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCKsWRmVeSWpSXmKPExsXCFe/ApetdXOlv8GehvMWtyZPYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVseHzB/aCLq2KHw0T2RsYjyp1MXJySAiYSFy4s5gRwhaTuHBv PVsXIxeHkMBGRomZXVOYIZzfjBKde36wg1QJCTQySsxZbg5iswioSkzZ8xusm01AXaLl6DcW EFtYwFqiZdk9NhCbU8BUYtvKqWBxEQEDiWXnH4DZzAKaEvtOHQGzeQUsJf4f38AMYQtK/Jh8 D6pGT+Ljn9uMELa4RHPrTai4tsSTdxdYQWxGoKu/n1rDBDHfRuLzy24gmwPI1pNYOVcBokRU 4k77eqgnBSSW7DnPDGGLSrx8/I8V4q07TBIzLzpMYBSfheSKWUiumIXkillIrljAyLKKUaw4 qSgzPaMkNzEzJ93AUC8jUy8zL7VkEyMkijJ2MC7fqXKIUYCDUYmH98eTCn8h1sSy4srcQ4yS HExKorxthZX+QnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4mRmBcrwpiZVVqUX5MCkZDg4lCd7X RUApwaLU9NSKtMwcYKqASTNxcIK08wC1/wep4S0uSMwtzkyHyJ9ilJQS5z0HkhAASWSU5sH1 vmIUBzpSmDcTJMsDTGpwXa+ABjIBDXz1txxkYEkiQkqqgdHIR/Oq8E69zf7XpkrO2NsVZvss MU1m0b/Gk18P7Vp02sTDcY9upnmqi82f3PhnjAEbPVfXVOolHdpi1TJTzeB5zCK+tUsuPzNZ 1sz0efWSFWvN2Vb+NfE9Z/fa+WvljCW566bw5t/Re9owmyvjsee0QtHyv1pyRQwl+eaZ67W/ cZ033b78xCclluKMREMt5qLiRADzf4zAJwMAAA==
References: <7AEB3D6833318045B4AE71C2C87E8E1720C8E5DC@dfweml511-mbx.china.huawei.com> <2C0E90B7-4B30-45F4-A7B0-1887E8654A66@cs.yale.edu> <4F6F686F.5020202@grotto-networking.com> <4F6FD6BE.2040606@cs.yale.edu> <4F71F275.4000800@grotto-networking.com> <29679E68-FD87-44EA-9908-BEE4940021D6@tid.es> <4F74A608.4060303@grotto-networking.com>
Cc: "altoext@ietf.org" <altoext@ietf.org>
Subject: Re: [altoext] i2aex BOF - Large Bandwidth Use Case
X-BeenThere: altoext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Non-WG list for discussions related to ALTO Protocol Extensions <altoext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/altoext>, <mailto:altoext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/altoext>
List-Post: <mailto:altoext@ietf.org>
List-Help: <mailto:altoext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/altoext>, <mailto:altoext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 09:37:19 -0000

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