- Nsi-wg - lists.ogf.org

Re: [Nsi-wg] Issue 32 in ogf-nsi-project: Interface version discovery
by ogf-nsi-project＠googlecode.com 17 Sep '12

17 Sep '12

Comment #3 on issue 32 by guy.robe...(a)gmail.com: Interface version discovery http://code.google.com/p/ogf-nsi-project/issues/detail?id=32 John M. has some ideas ... John to write-up a proposal.

1 2

Re: [Nsi-wg] Issue 24 in ogf-nsi-project: ServiceException needs further details
by ogf-nsi-project＠googlecode.com 17 Sep '12

17 Sep '12

Comment #6 on issue 24 by imo...(a)gmail.com: ServiceException needs further details http://code.google.com/p/ogf-nsi-project/issues/detail?id=24 Discussion on the Wed call 1. rename messageId to errorId 2. Appendix captures a list of errorId values and their meanings 3. errorId and text are both fields that are included by the entity Inder

1 3

Re: [Nsi-wg] Issue 39 in ogf-nsi-project: STP syntax
by ogf-nsi-project＠googlecode.com 17 Sep '12

17 Sep '12

Comment #2 on issue 39 by jmacau...(a)gmail.com: STP syntax http://code.google.com/p/ogf-nsi-project/issues/detail?id=39 I am confused by this agreement. An STP is defined as a OGF URN that is composed of the NSnetwork and localId already. Is this asking me to break out the STP into two discrete elements?

1 4

Issue 65 in ogf-nsi-project: Update WSDL for NSI 2.0 with new PathType definition
by ogf-nsi-project＠googlecode.com 17 Sep '12

17 Sep '12

Status: Accepted Owner: jmacau...(a)gmail.com Labels: Type-Defect Priority-Medium FoundInVersion-1.0 FixedInVersion-2.0 New issue 65 by jmacau...(a)gmail.com: Update WSDL for NSI 2.0 with new PathType definition http://code.google.com/p/ogf-nsi-project/issues/detail?id=65 Description of Issue: Current path and STP specification within the WSDL reservation message can be ambiguous to the path finding engines. Resolution of Issue: Modify WSDL to meet recommendation as discussed in weekly working group call, and as captured in document summary STPs_summary9 http://ogf-nsi-project.googlecode.com/files/STPs_summary9.pdf.

1 2

FW: Wednesday's NSI call
by Guy Roberts 12 Sep '12

12 Sep '12

Hello All, I am not able to join today' NSI call as I have other commitments today. Based on the conversation on the mailing list and Skype, I think we have a broad consensus on how Connection should be requested. The important next step is to agree the WSDL 'path' object. The attached document summarizes a WSDL structure that I believe reflects what has been agreed. I have added 2 attributes in red that have been proposed, but not agreed - please take a look. Regards, Guy

1 0

uml proposal for STPs
by Guy Roberts 12 Sep '12

12 Sep '12

Here is a possible unidirectional STP shown in UML format: [cid:image001.png@01CD8B82.09934C30] _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect DANTE Cambridge, UK +44 1223 371316 DANTE is the project co-ordinator and operator of GÉANT, the high-speed pan-European research and education network that is transforming the way researchers collaborate. Learn more at: www.geant.net<http://www.geant.net/> Like us on: www.facebook.com/GEANTnetwork<http://www.facebook.com/GEANTnetwork> Follow us at: www.twitter.com/GEANTnews<http://www.twitter.com/GEANTnews> DANTE is the trading name of Delivery of Advanced Network Technology to Europe Limited registered in England & Wales. Registration Number 2806796. Registered Office - 9400 Garsington Road, Oxford Business Park, Oxford OX4 2HN. _____________________________________________________________________

3 12

Wednesday's NSI call
by Tomohiro Kudoh 12 Sep '12

12 Sep '12

The following is dial-in information for Wednesday's NSI call, time: 7:00 PDT 10:00 EDT, 15:00 BST, 16:00 CEST, 23:00 JST 1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285 Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code 8937606, followed by "#" Agenda: ・ State Machine update ・ STP decision ・ WSDL and plan for OGF36/GLIF ・ Preparation of Connection Service protocol text. Tomohiro

1 0

Fwd: Re: uml proposal for STPs path object specifications...
by Jerry Sobieski 11 Sep '12

11 Sep '12

On 9/10/12 5:48 AM, Guy Roberts wrote: > > Jeroen, > > "IMO, what we need to do is provide a single forward path ERO. And > if the request is for a bi-directional service instance, then that > service provider identifies the appropriate reverse path for the > "bi-directional connection". If the requester specifies the forward > and reverese path, then it is just two uni-directional service > requests. And if so, then we should just do two requests so that the > user has the ability to define the two paths independently." > > This is a simple and quite elegant solution, but I have a strong > concern with this approach as it forces providers to describe their > topology using a network modelling method where all STPs map to > unidirectional STPs (exclusive use of bi-directional STPs would not be > allowed) . This is quite a severe constraint for transmission > equipment as ITU-T MIB models do not include uni-directional ports as > part of their model. > > Guy > Hi Guy- So here is a good point for NSI's technology agnostics. Whether some specific technology may or may not be accessible in a uni-directed or bi-directed fashion should not impose a requirement on NSI. If we elect to have NSI support STPs of one form or the other, or both, we leave it to the NRM to translate the NSI primitive appropriately to construct a service instance across the local intra-domain hardware that is consistent with the NSI service request. NSI should do what we deem best for the global inter-domain service framework - and let specific NRMs translate that abstract service model to specific hardware confiogurations. A very similar situation exists where a network implements what appears to be a VLAN service across say, an MPLS or SDH hardware infrastructure - the hardware configuration is resolved by the NRM not by NSI. Just because the service presents something that looks and feels like a VLAN to the user does not require that the instance is actually realized across ethernet hardware. So, even if some hardware can only support bi-directed configuration, that does not impose a requirement that NSI must support bi-directed STPs. (vice versa is true too - if NSI supports bi-directed connections only does not mean that only hardware that supports bi-directional configuration must be used...) This is why it is important to maintain technology agnostics. And further - even if we allow and support bi-directed STPs in NSI, does not mean that we should not support uni-directed connections across those STPs. A unidirectional request does not impose any requirements upon a reverse path - so a NRM could allocate the reverse path however it chose, or it could not, or ... We simply leave it to the NRM to decide how to put a uni-directed path across their STPs. I recommend that NSI recognize both Bi-directed STPs and Uni-directed STPs. NSI leaves it to the local network to decide whether to advertise their STPs as bi-directional or uni-directional. (Note- this does not require a network to expose any other hardware specifi details, nor does it require a network advertise anything more than we have already discussed.) This just says that *IF* you advertise an STP, you need to declare it bi-directional or uni-directional. I also recommend that NSI Reservation Requests now implement "directionality": uni-directional connection, or bi-directional connection. The path object is always considered to be the forward path only. I also recommend that if we agree that NSI supports bi-directional STPs, then we must also define the following "orientation" attribute for STP references: When an ERO element or the SourceSTP/DestSTP references a bi-directional STP(s), the reference must include an explicit "orientation" type-value pair to indicate how the STP is to be oriented relative to the forward path segment: <orientation="outbound"> indicates that the forward path will transit the STP from the intra-domain region towards the inter-domain region, and <orientation="inbound"> indicates that transit will occur from the inter-domain region towards the intra-domain region. The network identifier, or topology id, of the referenced bi-STP is considered the _/intra-domain/_ network for that STP. Note: if the specified STP is a uni-directional STP, the orientation is pre-defined in the topology - thus the "orientation" T-V pair may be omitted or null. But if orientation is specified in the path object associated with a uni-STP it must agree with the orientation defined in the topology. If it does not, it is an error and the request should be failed. I recommend NSI adopt the following behavior for path resolution: STP | UNI-STP | BI-STP Directionality | | ---------------+----------------------+----------------- UNI-dir: | Forward: use ERO | Forward: use ERO | Reverse: n/a | Reverse: n/a (NRM decides) ---------------+----------------------+----------------- BI-dir: | Forward: use ERO |Forward: use ERO | Reverse: PA selects |Reverse: use ERO To elaborate - a uni-dir connection with uni-STPs is fine, no reverse path. A bi-dir connection with bi-STPs is fine, the reverse path is taken from the bi-directional STPs. If a uni path is requested using bi-STPs, the forward path is built, but the reverse path is unneeded - it is left to the NRM to decide what happens along the "reverse path" (it may provision a reverse path anyway, or it may not...) For a bi-dir connection with uni-STPs, we have an issue - how do we select the reverse path? I suggest we let the PA (the network that defined the uni-STPs and is offering a bi-directional service) decide how to identify an appropriate reverse path....the RA did not specify STPs that had a reverse path, so it has essentially left the reverse path selection to the PA to choose. Thoughts? Jerry > > *From:*Jerry Sobieski [mailto:jerry@nordu.net] > *Sent:* 07 September 2012 11:16 > *To:* Jeroen van der Ham > *Cc:* Guy Roberts; nsi-wg(a)ogf.org > *Subject:* Re: [Nsi-wg] uml proposal for STPs path object > specifications... > > On 9/7/12 2:26 AM, Jeroen van der Ham wrote: > > > > On 6 Sep 2012, at 23:56, Jerry Sobieski<jerry(a)nordu.net> <mailto:jerry@nordu.net> wrote: > > > > I do not believe it is appropriate or useful to distribute the "topology ID" across both the source and sink localids. This forces both source and sink to be part of the same network topology...why? What value is this? This does not force any relation to exist between the source and sink ports besides being part of the same topology file - so what is the use case or value of it? We should specify each STP 2-tuple independently. > > > > No, the question should be the reverse, why would you ever want to have a reservation request with two different topology IDs in it? > > Yes I Agree. So what we have in the proposed triple form - _even > with a single topology id _- is the ability to specify forward and > reverse transit points that are widely geographicaly separated. There > is no significant constraints imposed by a single topology. So while > I agree with you that we do not want any particular hop to have widely > geographically diverse forward and reverse paths, /_a single topology > ID does not accomplish this._/ > > IMO, what we need to do is provide a single forward path ERO. And if > the request is for a bi-directional service instance, then that > service provider identifies the appropriate reverse path for the > "bi-directional connection". If the requester specifies the forward > and reverese path, then it is just two uni-directional service > requests. And if so, then we should just do two requests so that the > user has the ability to define the two paths independently. > > THis is why I am suggesting we have a single forward path ERO, and the > reverse path is not specified in a request. If the request is a > bi-directional connection, the provider will build the reverse path. > So for such EROs there is not need for a triple at all...just the > topology id and port id of the forward path. > > make sense? > J > > > > > Think about what an NSA would do with that message, how would it handle that? It would have to forward half of the request to someone else? Why are the two unidirectional connections in the same request? Is there some reason that the need to be together? > > Basically, having the possibility of two different topology IDs in a reservation request for one end of a connection opens up a huge can of worms for unexpected behavior. And it does not add anything we can already do. You can simply divide up your two unidirectional connections and request them separately with the same mechanics that we already have without having to change anything. > > Jeroen. > >

1 0

ISC Cloud
by Sperber, Rolf (Rolf) 10 Sep '12

10 Sep '12

Dear colleagues, Wolfgang asked me to forward the following text. I am happy to do so since I consider this event most interesting for people involved in HPC, Cloud and high performance networking: Dear Colleague, please consider this International Conference on Cloud Computing: ISC Cloud'12 - HPC & Big Data Meet Cloud While cloud computing is gaining traction for enterprise computing, the suitability of such centralized computing resources for meeting the demand for high performance computing (HPC) and big data continues to be widely discussed and analyzed. On September 24-25, 2012 cloud computing experts and end-users from around the world will gather at the 3rd ISC Cloud Conference at the Dorint Hotel in Mannheim, Germany. The conference will focus on compute and data intensive applications, their resources needs in the cloud, and strategies on implementing and deploying cloud infrastructures, for industry and academia. Please go to http://www.isc-events.com/cloud12/ to find out all about the conference. ISC Cloud'12 is the third conference in the series and is presented by the same organization that hosts the International Supercomputing Conference (ISC). The key topics of the ISC Cloud'12 are: - Keynote Session with CERN's Bob Jones, Rupert Lueck from EMBL, and Wolfgang Lengert from ESA - Industrial Cloud Best Practices - Academic Cloud User Experiences - Engineering Applications in the Cloud - Modeling HPC Clouds - Key Security & Compliance Issues - Critical Aspects of HPC & Big Data Clouds - and a cloud vendor panel including a tabletop exhibition, full catering, and an evening event at a famous winery in the Pfalz Rhine Valley, as well as the conference proceedings. Please register at http://www.isc-events.com/cloud12/Registration/Online-Registration We look forward to welcoming you in Mannheim in September! Best regards, Wolfgang Gentzsch, Chairman ISC Cloud'12 PS: Some of the participating organizations are: CERN, EMBL, ESA, HP, Intel, IBM/Platform Computing, Nvidia, Alcatel-Lucent, Intersect360 Research, Schrödinger Inc., IDC, EU, Fraunhofer ITWM, Fraunhofer SCAI, The Cloud Security Alliance, ICT Legal Consulting, Univa, Rutgers University, Oxford eResearch Centre, Rutherford Appleton Laboratory, INRIA, Mellanox, Samsung, adaptec, Bull, Bright Computing, T-Systems, SGI, HPC in the Cloud, HPCwire, InsideHPC, iSGTW, and the Linux Magazine. ---- ISC Cloud'12 http://www.isc-events.com/cloud12 ---- Wolfgang Gentzsch, Executive HPC Consultant http://www.linkedin.com/in/wolfganggentzsch ========================================================================= ========================================================================= [cid:image001.jpg@01CD8ED5.532982A0] Rolf Sperber ALCATEL-LUCENT DEUTSCHLAND AG End to End Solution Architect Lorenzstrasse 10 70435 Stuttgart Phone: (+49) 7255 724720 Mobile (+49) 171 8625912 rolf.sperber(a)alcatel-lucent.com<mailto:rolf.sperber@alcatel-lucent.com> Alcatel-Lucent Deutschland AG Domicile of the Company: Stuttgart * Local Court Stuttgart HRB 4026 Chairman of the Supervisory Board: Michael Oppenhoff Board of Management: Wilhelm Dresselhaus (Chairman) * Hans-Jörg Daub . Dr. Rainer Fechner * Andreas Gehe Diese E-Mail-Nachricht und ihre etwaigen Anlagen können vertrauliche Informationen enthalten. Wenn Sie diese E-Mail-Nachricht irrtümlich erhalten haben, bitten wir Sie, uns dies mitzuteilen und die E-Mail und ihre etwaigen Anlagen sowie etwa hiervon gefertigte Kopien umgehend zu vernichten. Die irrtümlich erhaltene E-Mail und ihre etwaigen Anlagen dürfen weder weitergeleitet noch anderweitig verwendet werden. This e-mail and its attachments, if any, may contain confidential information. If you have received this e-mail in error, please notify us and delete or destroy the e-mail and its attachments, if any, immediately. If you have received this e-mail in error, you must not forward or make use of the e-mail and its attachments, if any.

1 0

STPs in connection requests
by Guy Roberts 06 Sep '12

06 Sep '12

The attached document shows 3 options that I see for representing STPs 'references' in connection requests. Comments on the different options to the STP skype chat group please! Guy _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect DANTE Cambridge, UK +44 1223 371316 DANTE is the project co-ordinator and operator of GÉANT, the high-speed pan-European research and education network that is transforming the way researchers collaborate. Learn more at: www.geant.net<http://www.geant.net/> Like us on: www.facebook.com/GEANTnetwork<http://www.facebook.com/GEANTnetwork> Follow us at: www.twitter.com/GEANTnews<http://www.twitter.com/GEANTnews> DANTE is the trading name of Delivery of Advanced Network Technology to Europe Limited registered in England & Wales. Registration Number 2806796. Registered Office - 9400 Garsington Road, Oxford Business Park, Oxford OX4 2HN. _____________________________________________________________________

1 1