October 2011 - Nsi-wg - lists.ogf.org

Re: [Nsi-wg] Issue 2 in ogf-nsi-project: GenericAcknowledgmentType
by ogf-nsi-project＠googlecode.com 12 Jan '12

12 Jan '12

Comment #11 on issue 2 by imo...(a)gmail.com: GenericAcknowledgmentType http://code.google.com/p/ogf-nsi-project/issues/detail?id=2 This was re-discussed on the Wed. call, with the following results: 1. Message transport layer takes care of ack retransmission in case of a packet loss. 2. Confirm/Fail message responses should be sent out without waiting on the receipt of the message ack. [comment on error recovery: if message transport layer is broken, say unidirectionally, the ack sending will eventually timeout and generate a message transport error that the NSA will need to handle] 3. From the receiving state machine perspective, receiving a confirm/fail message from a particular NSA should cancel out the need to receive an ACK. So the state machine should not only continue to process the confirm/fail message, but not gate on or wait for the ACK message. Hope this resolves this issue

1 2

Issue 48 in ogf-nsi-project: Addition of a Failed state into the state machine.
by ogf-nsi-project＠googlecode.com 08 Dec '11

08 Dec '11

Status: Accepted Owner: jmacau...(a)gmail.com Labels: Type-Defect Priority-Medium FoundInVersion-1.Rio FixedInVersion-1.1 New issue 48 by jmacau...(a)gmail.com: Addition of a Failed state into the state machine. http://code.google.com/p/ogf-nsi-project/issues/detail?id=48 Description of Issue: There is no way within the existing NSI state machine to determine if a reservation in the "Terminated" state reached that state through a successful execution or through a failure. Discussion of Issue: For example, a reservation is modelled by a state machine once a reserve.rq is sent and the state machine transitions from the "Initial" to the "Reserving" state. If the reserve.rq fails the existing state machine transitions into "Cleaning" and then to a final rest state of "Terminated". Likewise, a successfully executed schedule reaches the final rest state of "Terminated". An observer using the query operation would not be able to distinguish the failed schedule from the successful schedule after the fact. It can be even more confusing in that one schedule may have failed do to a second schedule, but there is no way to tell which after they have completed. There are two possible solutions: 1. Add a new "Failed" state to the state machine. 2. Add an informational field to the state machine / reservation record that tracks the reason for transition into the "Terminated" state. We could model a successful schedule that reached endTime. A manual terminate. A forcedEnd received from a child or local NRM. A reservation failure (could store the ServiceException). I do not believe the argument that this is an OAM issue and needs to be solved separately is valid in this case. We need additional information. Resolution of Issue: I would recommend option #2.

1 1

Issue 42 in ogf-nsi-project: Query details and summary
by ogf-nsi-project＠googlecode.com 08 Dec '11

08 Dec '11

Status: Accepted Owner: ---- Labels: Type-Defect Priority-Medium FoundInVersion-1.0 FixedInVersion-1.1 New issue 42 by thost...(a)gmail.com: Query details and summary http://code.google.com/p/ogf-nsi-project/issues/detail?id=42 I don't quite understand why we cannot just have one query mode, instead of the Summary and Details mode. Why not just have a single mode, which returns all the information? AFAICT none of the information requires a recursive query. Furthermore the current scheme actually prevents one from getting the current connection state and the list of children, which is rather unfortunate as that is exactly what I would like to have for the connection visualization tool. Is there any reason these two modes cannot be conslidated into one?

1 2

NSI TNC 2012
by Radek Krzywania 22 Nov '11

22 Nov '11

Hi, are there any plans for NSI on TNC 2012? I've just got a call for paper on it. We could write a paper on demo/development experience and show current features and service cover map. What do you think? Deadline is end of Nov. Also maybe it will be feasible to have a demo there, unless not much new will be available after SC. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania(a)man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________

6 5

f2f session at SC11
by Tomohiro Kudoh 16 Nov '11

16 Nov '11

Hello all, I propose to have a f2f meeting at SC11 in the morning of Wednesday (Nov. 16), at AIST booth. Will this work for you? Please let me know your convenience. Tomohiro

5 8

NSI demos for Supercomputing
by Jerry Sobieski 01 Nov '11

01 Nov '11

Hi All- I hope you all had a nice well deserved and relaxing weekend. Alas, we must get started on the final stretch this year and prepare for the Supercomputing demos... (there must be some cosmic justice to the fact that "demonstration" begins with "demons"...) The focus for SC will be to consolidate, stabilize, and demonstrate our existing capabilities. So, our target topology will be the topology we used last week for FIA, plus any added GOLEs or Networks that participate. There are two ways to participate: a) as an NSI network running an NSA, or b) as a supporting organization that is willing to lend transport resources between these NSI networks or is willing to help write software tools, etc. I will acknowledge all organizations on the posters/handouts. ---> I want to freeze the topology by November 7th so that applications building off the diagrams don't have to keep fixing their graphics everytime someone realizes they want to participate...So if you want to be part of this, let me know ASAP. (That means yesterday!:-)) The fundamental objective of the SC demo is to set up circuits using NSI-CS across multiple domains and over real hardware. So each network will need to verify their 1) control plane interoperability with the other NSAs, and 2) insure that their data plane is properly configured between your network and your adjacent peer. Attached is the initial topology diagram and the associated .owl file for SC - SC2011-Topo-v1.0 Changes from latest FIA topo: - Added STPs for USLHCnet between NL and SL. For SC, we will again use only four VLANs on each link: 1780 to 1783. In some locations we may need to only use a subset of these depending upon how the NSAs are resolved by next week. Tasks: For the GOLE/network operators: pursue the following tasks: 1) Every network should have at least one end system that can be used to terminate circuits and that can issue and respond to IP layer Pings. This could be a perfSonar host with apropriate access provided to the demo team, or a small Linux or Mac, or possibly the switch processor itself. But we need something we can use to test to, and access to configure and verify the circuit. 2) Control plane: Begin testing immediately from your NSA to your neighbor's NSA to set up simple intra-domain Reservation Requests across your neighbor's network, and then progress to test inter-domain reservations across your network *and* your neighbor. THis is to insure proper and reliable interoperability between NSAs. Coordinate with your neighbor network (you all know the PoCs by now) to test. 3) Data plane: Ping test the connections to your neighbors' networks to insure the VLANs are clear channels between the NSI Networks. The crossconnects within your networks will never work if the static VLANs between networks are not operational first. So _/verify these VLANs/_ by manually placing an end system from each network on each VLAN, configuring the IP subnet, and pinging one another. For the code developers: 1) Make sure your hardware/NRM interfaces are working reliably. 2) Make sure you are able to deal with SOAP/HTTPS messaging. If you need to implement it - now is the time. If there are issues doing so, lets get those exposed so that we can resolve them. Monitor the nsi-wg chat on Skype... 3) Make sure the Query command is working properly. 4) Lets get the Query Agent, the MotherEarth (autoEarth) vizualizer, and the AIST-vizualizer working *RELIABLY*. You all should dive into this as soon as the SC WSDL interop, query interop, and HTTPS is working. This is the capstone task for this year!!! These visualizers will exercise and demonstrate all of the other great work we've accomplished. So let make these look good! Thanks all.... Any additions, corrections, thoughts, or comments, please post or send them to me and we'll integrate them into the task tracking... Two weeks till Showtime! Jerry

2 1

Interoperability matrix for SC
by Takahiro Miyamoto 31 Oct '11

31 Oct '11

Hi all, I made a matrix sheet for interoperability of WSDL 1.SC instead of the matrix for 1.Rio. https://docs.google.com/spreadsheet/ccc?key=0AkOr3QHUMxp-dFB6TDRtajNQYUl3bm… Please update your status. Best regards, Takahiro -- Takahiro Miyamoto <tk-miyamoto(a)kddilabs.jp> KDDI R&D Laboratories, Inc. TEL: +81-49-278-7455 / FAX: +81-49-278-7811

1 0

NSI demonstration at FIA in Poznan
by Radek Krzywania 28 Oct '11

28 Oct '11

Hi all, We have a working successful presentation of NSI with data plane enabled. We are able to setup a global circuit between PIONIER and AIST networks in automated manner. The control plane is successfully visualised on Automated Earth interface and a data plane is verified with ICMP messages (PING). Thanks to involvement of many individuals and organisations, we have made a big step in the direction of SC'11 demo and further NSI development. I would especially thank Michał Balcerkiewicz (PSNC), Jeroen van der Ham (UvA), Takatoshi Ikeda (AIST), Tomohiro Kudoh (AIST), Henrik Thostrup Jensen (NORDUNET), Gerben van Malenstein (SURFNET), John MacAuley (SURFNET) and Jerry Sobieski (NORDUNET) for sacrificing their time and did the best to make it working (apology if I missed here anyone). The NSI booth and a demo was visited by multiple conference participants, including representatives of Brasilian NREN RNP, I2CAT, University of Essex, GEANT, GRNET/NTUA, NextWorks and more. Once again, thank you all NSI folks for helping with this event and demo preparation and execution! Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania(a)man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________

2 1

FIA-Topo-v1.4d
by Jerry Sobieski 27 Oct '11

27 Oct '11

Hi all- Here is version 1.4d topofile. Changes: - set up vlan 1781 to be statically configured thru NetherLight from Pionier to StarLight. (commented out the 1781 STPs in NL on the pionier port and the SL port, and set the remote peer in the ports at SL and Pioner. - updated the csProviderEndpoint for pionier. - modified the Location object for GEANT to point at Paris rather than Cambridge. Thanks Jerry

3 2

Tomorrow's NSI call - please respond.
by Inder Monga 26 Oct '11

26 Oct '11

Hi All, Please let the list know if you can make the call tomorrow and if you are prepared to talk about Security. This is an important topic and I would love to have as close to full attendance as possible so we do not have to re-do the discussion. Your response is appreciated, Inder -- Inder Monga 510-486-6531 http://www.es.net Follow us on Twitter: ESnetUpdates/Twitter <http://bit.ly/bisCAd> Visit our blog: ESnetUpdates Blog <http://bit.ly/9lSTO3><http://bit.ly/d2Olql>

3 3