- Nsi-wg - lists.ogf.org

Thank you!
by Gerben van Malenstein 24 Jan '14

24 Jan '14

Hi NSI-WG, Thank you for your kind card and present, we'll enjoy the gift card soon! Best regards, Gerben

1 0

Re: [Nsi-wg] Topology Service Requirements document
by Freek Dijkstra 23 Jan '14

23 Jan '14

In a off-list discussion, the "topology updates (i.e. partial topology documents)" mentioned in the presentation of Chin at OGF40 came up. (https://redmine.ogf.org/dmsf_files/13191) I hope Chin of Inder can clarify the following: What does such "partial topology" entail? * Is that the collection of full topologies from those domains whose topology has updated since a given timestamp? or * Is that a subset of a topology from a given domain that consists of the resources and relations that have been changed/added/removed since a given timestamp? During the presentation I assumed the later, later someone (I forgot who) convinced me it was the former. The former seems a lot more simple to implement, but re-reading the slides after Miroslav's questions I'm in doubt again. Freek

2 1

NSI-CS v2 final schema
by John MacAuley 23 Jan '14

23 Jan '14

Peoples, I was asked to send out a clarifying e-mail on the topic of the WSDL version being standardized. The submitted NSI-CSv2 document uses the schema identified by update r117. This included a fix to like the schema up with the NSI-CSv2 document: "An instance of the PSM for a reservation is created in the Released state when the first reserve request is received, however, a provision request cannot be processed until the first version of the reservation has been successful committed." For those coding with r116 just make sure you create the PSM when creating the RSM and LSM so it will be compatible with those using r116. John

1 0

Minutes: GLIF NSI Implementation Group (Jan 22, 2014)
by John MacAuley 22 Jan '14

22 Jan '14

Attendees (please let me know if I missed anyone): John MacAuley, ESnet Henrik Thostrup Jensen, NORDUnet Radek Krzywania, Poznan Supercomputing and Networking Center Joe Mambretti, Northwestern Hans Trophert, SURFnet Alex Moura, RMP Freek Dijkstra, SURFsara Jerry Sobieski, NORDUnet Chin Guok, ESnet Inder Monga, ESnet Guy Roberts, DANTE 1. John presented the attached slide package discussing the mandate of the group, how we would like to operate, and how we would like to interact with existing NSI related groups. Key point: Items will be discussed within the group only when a contribution has been made available 4 - 5 days before the meeting. We need focus to avoid wandering discussions. 2. Discussed a list of topics we need to address in the short term. a) Discovery Service - expand the existing discovery service proposal to cover new requirements from existing NSI implementations and changes in NS 2.0. Action: John and Henrik to work together to revise the existing discovery service contribution for review. Expecting prototype implementation to validate contribution. b) Ethernet Service - we are using VLAN labels in the A-GOLE topology that are yet to be specified in a formal schema with a defined namespace. We have agreed to capture the existing Ethernet parameters and formalize the definition. Action: John to capture existing parameters and define in a formal schema definition for review. c) Error handling - Expand existing NSI error set to include new errors values introduced through NSI 2.0 implementations. Define required error feedback for taking corrective action on the errors (especially for path finding). Action: John to write contribution as an initial proposal for discussion. d) AAI - Hans has a proposal for end user authentication and authorization that will be running in the European production network, and we hope on the A-GOLE. He will bring in a formal contribution for review. Action: Hans to write a contribution for review. e) Requirement for path finding - Formalization of topology requirements for pathfinding (both chain and tree). f) Topology discovery - We have two primary use cases for topology exchange; support of dissemination of information for full tree based path finding, and summary path vectors for chain based routing. Action: Chin to update his OGF contribution with input from Henrik, and review proposal. Expecting prototype implementation to validate contribution. 3. Jerry related concerns that standardization activities need to occur in the OGF NSI-WG and not the GLIF NSI Implementation group. Discussion occurred around providing implementation feedback on the standards into the GLIF NSI Implementation group so solutions can be vetted, and formal contributions defined for submission back into the OGF NSI WG. Action: Inder, John, and Jerry to discuss concerns and propose resolution. Please let me know if I have missed anything. Next Wednesday is the OGF NSI WG meeting, and back to the GLIF NSI Implementation group meeting in two weeks. Thank you, John

1 0

NSI Implementation call tomorrow morning 7 am PST (same slot, same bridge as NSI)
by Inder Monga 22 Jan '14

22 Jan '14

Dear Friends, As you probably saw the email from Guy, NSI 2.0 specification is finalized and now in public comment. In addition, the group discussed the need for NSI implementation agreements to help deploy NSI operationally. The GLIF NSI Implementation working group was formed, but was not in full swing waiting for 2.0 to be finalized. Lars was very supportive and happy to have those discussions as part of the NSI Implementation within the GLIF tech working group - with a face to face meeting colocated with GENI in Atlanta in March. The consensus in the OGF group was to alternate NSI standards discussions with NSI implementation - but hold them in the same timeslot as people already have that time reserved (and not increase the number of meetings). John and I will discuss the objective, process and schedule for discussions of NSI Implementation group, and a set of topics that fit within that scope. We invite participation and contributions from folks looking to deploy NSI. A set of slides presented at OGF is attached for your review. The dial-in information stays the same The following is dial-in information for Wednesday's NSI call, time: 7:00 PDT 10:00 EDT, 15:00 GMT, 16:00 CET, 24:00 JST 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 "#" Look forward to your participation tomorrow, John and Inder

2 1

Fwd: Reminder to ReadyTalk Users: Use VoIP
by Inder Monga 22 Jan '14

22 Jan '14

FYI - an internal notice of the ability to use VOIP with readytalk bridge that we use for NSI calls. This should help if you are traveling and have IP connectivity. Inder From: ReadyTalk on Behalf of ECS <kim.morse(a)readytalk.com> Date: Tue, Jan 21, 2014 at 12:40 PM Subject: Reminder to ReadyTalk Users: Use VoIP To: imonga(a)es.net If you have trouble viewing this email, read the online version<http://s1904.t.en25.com/e/es.aspx?s=1904&e=68405&elq=e8c1825e990042bcaabfb7…>. <http://s1904.t.en25.com/e/er?s=1904&lid=38&elq=e8c1825e990042bcaabfb7ee5cda…> <http://s1904.t.en25.com/e/er?s=1904&lid=11&elq=e8c1825e990042bcaabfb7ee5cda…> <http://s1904.t.en25.com/e/er?s=1904&lid=2786&elq=e8c1825e990042bcaabfb7ee5c…> <http://s1904.t.en25.com/e/er?s=1904&lid=41&elq=e8c1825e990042bcaabfb7ee5cda…> Dear Inder , As a valued customer of our ReadyTalk service we would like to remind about a new feature recently released by ReadyTalk – VoIP audio conferencing. As an ECS ReadyTalk user hosting a number of conferences with International participants, you can help us manage costs by using ReadyTalk’s VOIP feature. Rather than call into meetings using your telephone, you can simply initiate ReadyTalk VOIP services in the web interface and use your computer speakers and microphone for the audio portion of your conference. Using VOIP will significantly reduce the conference call costs. International conferencing is one of the fastest growing segments of this collaboration service and we are seeing increasing international connection costs. Here is some quick guidance on how to use ReadyTalk VOIP: - As a meeting host, log into your ReadyTalk Conference Controls and click the ‘Use Computer’ option on the left side under ‘Audio Controls’. From the Mic and Speaker dialog box, select your hardware from the drop down menu. - Meeting participants will have the option to join with a VoIP connection directly from their participant application, once the host has started the meeting. - Hosts should instruct participants to select the Audio button at the top of the participant window. Select Use your Computer Mic and Speaker option. Select their available microphone and they will automatically join the audio meeting from their PC. - As with any form of conference calling you should instruct your participants to mute their microphones if they are not speaking. - For optimal audio quality, we recommend that individuals utilizing VoIP use a headset that is plugged in via their USB port. On your next International call try the new VOIP feature and please ask your participants to try the new VOIP feature as well. Let us know how well the VOIP services worked for your conference by sending email to ecs-admin(a)es.net. Thank you. Sincerely, ECS ReadyTalk Team To unsubscribe from future emails or to update your email preferences click here<http://meet.readytalk.com/content/PrefCenter?elq=e8c1825e990042bcaabfb7ee5c…>. ReadyTalk | 1900 Sixteenth Street | Denver, Colorado 80202 800.843.9166 Privacy Policy<http://www.readytalk.com/about/privacy-policy.php?elq=e8c1825e990042bcaabfb…>

1 0

NSI CS v2.0 available for public comment
by Guy Roberts 20 Jan '14

20 Jan '14

Hello all, The NSI CS v2.0 document was posted for 60 day public comment on Friday 17th January. You can view the document and post your comments here: http://redmine.ogf.org/projects/editor-pubcom/boards/18 Guy -----Original Message----- From: wg-all-bounces(a)ogf.org [mailto:wg-all-bounces@ogf.org] On Behalf Of Greg Newby Sent: 17 January 2014 23:01 To: All WG Subject: [wg-all] New document in public comment: NSI Connection Service v2j Dear OGF Community: A new document has begun public comment. Please consider reading and providing feedback. Brief affirmations are very useful to demonstrate community input and support. More detailed analysis is, of course, welcome. All documents in public comment are accessible here: http://redmine.ogf.org/projects/editor-pubcom/boards Note that this is an updated location, using OGF's new Redmine tracker system. Anyone may register for a Redmine username. This document is newly available for public comment: * NSI Connection Service v2, Recommendation track, via NMI-WG -- Greg Newby, OGF Standards Editor Dr. Gregory Newby, Director of the Arctic Region Supercomputing Center Univ of Alaska Fairbanks-909 Koyukuk Dr-PO Box 756020-Fairbanks-AK 99775-6020 e: gbnewby(a)alaska.edu v: 907-450-8663 f: 907-450-8603 w: people.arsc.edu/~newby -- The wg-all mailing list is an umbrella list for all OGF mailing lists. If you are subscribed to any OGF mailing list, you will receive mails to wg-all. wg-all mailing list wg-all(a)ogf.org https://www.ogf.org/mailman/listinfo/wg-all

1 0

URGENT: contact of Tomohiro Kudoh
by Freek Dijkstra 17 Jan '14

17 Jan '14

Tomohiro left his laptop at the conference site. Unfortunately I do not have his phone number. If any of you do, please give him a call. I will leave the laptop at the reception of the mathematics building. Thank you! Freek

3 2

NSI Identifier format
by John MacAuley 17 Jan '14

17 Jan '14

NSI has the requirement that the networkId of a resource must be parseable from the resource identifier. This is especially true for the STP identifier as we have a specific requirement that an STP identifier need not be exposed in topology, and therefore, the network identifier must be derivable from the STP identifier if the target network is to be determined. The current URN format specification document published by the NML group for use as identifiers in NML [ref] defines the resource identifier as opaque, which also implies non-parseable. We need to resolve this issue. I have captured a proposal below for an NSI identifier that removes the opaque URN restriction and imposes structure on the URN. I hope this generates positive discussions :-) <NSI identifier> ::= <prefix> ":" <organization> ":" <type> <prefix> ::= "urn:ogf:network" <organization> ::= <string> <type> ::= <nsa> | <network> | <stp> | <sdp> | <serviceAdaptation> | <serviceDomain> | <service> <nsa> ::= "nsa:" <nsaId> <nsaId> ::= <string> <network> :: = "network:" <networkId> <networkId> ::= <string> <stp> ::= "stp:" <networkId> ":" <stpId> <stpId> ::= <localId> <label> <label> ::= “?” <labelType> “=” <labelValue> | “?”<labelType> | “” <labelType> ::= <string> <labelValue> ::= <string> <sdp> ::= "sdp:" <sdpId> <sdpId> ::= <string> /* Should this be some type of source/destination stpId combination. */ <serviceAdaptation> ::= "serviceAdaptation:" <networkId> ":" <serviceAdaptationId> <serviceAdaptationId> ::= <string> <serviceDomain> ::= "serviceDomain:" <networkId> ":" <serviceDomainId> <serviceDomainId> ::= <string> <service> ::= "service:" <networkId> ":" <serviceId> <serviceId> ::= <string>

1 0

slides presented at OGF40 Oxford
by Guy Roberts 16 Jan '14

16 Jan '14

Hello All, The slides presented at the NSI working group meetings are available to download here: https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6573 Guy

1 0