- Nsi-wg - lists.ogf.org

NSI service
by Michał Balcerkiewicz 07 Sep '11

07 Sep '11

Hello, I want to clarify a bit on NSI services - currently when generating sources from the NSI wsdls we get two services (RA and PA) and each one has its own url. I try to combine them together so they will be accessible under a single url, suitable for csProviderEndpoint. Br michal

5 14

HTTPS and BASIC authentication
by John MacAuley 07 Sep '11

07 Sep '11

Can everyone please set up their NSA for HTTPS and BASIC authentication? You can either allocate a single account for all NSA to use, or you can specify an account for each of the NSA. I think either would be fine. I just want to make sure we can demonstrate a functioning secure transport. Thank you, John.

1 0

test2 to see if nsi-wg mailing list is working again
by Joel Replogle 06 Sep '11

06 Sep '11

Testing to see if the nsi-wg maling list is back in operation. Thanks, Joel -------------------------------------------------------------------- Joel Replogle Executive Director, OGF replogle(a)ogf.org http://www.ogf.org PO Box 1738 T: +1-765-228-9068 Muncie, IN 47308 USA F: +1-815-927-6284 Upcoming Events: OGF33 * September 19-23, 2011 * Lyon, France * www.ogf.org/OGF33 OGF34 * March 12-14, 2012 * Oxford, UK * www.ogf.org/OGF34

1 0

OpenDRAC topology example
by John MacAuley 06 Sep '11

06 Sep '11

Peoples, I modified the example topology to show the urn:ogf names for elements to help clarify. These are the formats that should be in the messaging. John.

1 0

test message to nsi-wg mailing list
by replogle＠www.ogf.org 06 Sep '11

06 Sep '11

This is a test to see if the nsi-wg mailing list is working again. Thanks, Joel

1 0

minutes from Wednesday's NSI call
by Guy Roberts 06 Sep '11

06 Sep '11

Now that Gridforge is back up, I have posted the minutes from this week's NSI conf call here: http://forge.gridforum.org/sf/go/doc16321?nav=1 _____________________________________________________________________ ** Guy Roberts, PhD Network Engineering & Planning * * Tel: +44 (0)1223 371300 * * City House Direct: +44 (0)1223 371316 * 126-130 Hills Road Fax: +44 (0)1223 371371 * Cambridge * CB2 1PQ E-mail: guy.roberts(a)dante.net<mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

2 1

Tomorrow's NSI conf call
by Guy Roberts 06 Sep '11

06 Sep '11

Hi all, 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 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: NSI Plugfest preparation Guy _____________________________________________________________________ ** Guy Roberts, PhD Network Engineering & Planning * * Tel: +44 (0)1223 371300 * * City House Direct: +44 (0)1223 371316 * 126-130 Hills Road Fax: +44 (0)1223 371371 * Cambridge * CB2 1PQ E-mail: guy.roberts(a)dante.net<mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

1 0

Test email - please ignore
by Jerry Sobieski 06 Sep '11

06 Sep '11

Foo.

1 0

Rio Inter-Domain Topo Ring v1.1a
by Jerry Sobieski 06 Sep '11

06 Sep '11

Here is an update on the inter-domain topology OWL file (the Rio Ring). ---> I deleted the intra-domain Ports. ---> Corrected a mispelled object name. ---> Added the csProviderContact URL to the NSA object for Aruba (OpenNSA), Bonaire (OpenDRAC), and Curacao (AutoBAHN.) Others- please forward me a contact place for your NSA. ---> Added Admin contact info to the NSA adminContact field. Note- the SNE graphical display only shows a single link between objects for connectTo, and mapsTo relations...The RDF is actually correct in showing relations both directions, but the editor somehow combines them to a single line. This topology now contains only NSnetwork objects, STP objects, and NSA objects. Each implementation will need to edit this topology file to map their STPs to the corresponding internal ports. The mapping is done by inserting the string representing the internal port into the "mapsTo" field of the corresponding STP. A reverse relation should be provided mapping the internal port to the STP. Each NSA/network must do this for every STP in their assigned network. Each network is free to define an internal topology as is most convenient for them. The only requirement on internal topology is that the STPs defined in the inter-domain topology must map to internal ports with the following characteristics: a) 1000 megabits/second max capacity, and b) untagged. If your internal topology is static, you can send me your updated OWL file and I will integrate the mapsTo fields into my global topology file and then subsequent topology updates will have your mappings already included... Tip: The DToX ontology used for the Rio NSI Topology still supports the Node, Port, and several other topology objects. These can be used by the respective networks to define internal topology that is compatible with the inter-domain topology if they so choose. If you need *ANY* help with this at all, explainations, advice, questions, etc... PLEASE!!! Let me know! We are up against the wall now...simple is better...If I can simplify things for you I am glad to do so. Best regards! Jerry

4 7

Topology version 1.1c
by Jerry Sobieski 06 Sep '11

06 Sep '11

Hi all- Last week someone noticed that the names of the networks and STPs in the RDF/OWL files did not conform to the URNs described in the NSI CS spec. So in exploring this issue, I believe we have a conflict in the URNs. And since I do not want to distract any further from the development, I am specifying a Rio topology database that avoids the issue completely. We can discuss it in Rio after the demo:-) So to avoid a long discussion prior to Rio, I am circulating a new topology file. This file describes the Rio Ring as before but with the following changes: 1. The "http://glif.is/.../detox#" prefix has been removed from the all Resource names and references. 2. The names are NOT the URN form; they are just the simple strings that identify the object. The issues I found confusing are: - First, the NSI spec defines an STP to have a network identifier and an endpoint identifier of the form: urn:ogf:network:STP:<networkname>:<endpointname> ...an attempt to capture the NSI tuple notion we've been using for NSI. A similar URN exists to specify network names: urn:ogf:network:NSnetwork:<networkname> If we substitute the network URN as the <networkname> in the STP URN we get a rather unusual URN result: Example: urn:ogf:network:STP:urn:ogf:network;NSnetwork:Aruba:Aiden This funky URN is at least one interpretation of the spec. I don't think this is what was intended. The confusion comes from the <networkname> portion of the STP URN - is this *really* a "network" name? ...Or just another namespace qualifier that insures the unique scoping for the <endpointname> component? If it really is a network name, then you get the funky URN. If it is just meant to add additonal namespace scoping, then *any* tag could be used in the <networkname> component - i.e. it does not have to be a network name at all. Which is fine...except that the STP URN would no longer uniquely identify an STP, it would just be a unique endpointname that could belong to *any* network. I believe there is the assumption that the STP URN contains a valid network name that can be used to locate the NSA associated with that STP. IMO, this is a problem in the spec and is pretty fundamental to the protocol. - Second, the NSI CS spec governs what should be in the CS protocol messages, not what should be in a topology database. So we don't strictly need to have the URNs in the topologyDB as there is no topology model or standardized database structure that requires it. Therefore, as long as we know how to map a NSI-CS URN to the name of the desired object in the topoDB, or vice versa- construct a URL from the object name in the topoDB, we should be fine - at least for Rio. - Third, what is "best" for the topologyDB depends a lot on how the various NSAs intend to use or represent that topology. And its not clear to me how the various NSAs are using the STP and NSobject URNs. Example: the endpoint "A1" in network "Aruba". The namedindividual object for the STP A1 is now called just "A1"...not "http://glif.is/working-groups/tech/detox#A1", nor is it called "urn:ogf:network:STP:Aruba:A1" Likewise, the NSnetwork topo object is called "Aruba", not "http://glif.is/working-groups/tech/detox#Aruba", nor is it called "urn:ogf:network:NSnetwork:Aruba" Note: the resource /types/ were not modified. These still use the glif.is/...dtox prefix. (I wasn't sure if changing these would break the RDF) For Rio, I have insured that all objects will have unique short names ala A1, B2, M3, etc. across the global topology. Therefore, you can locate the STPs associated with a Network by: "Aruba hasSTP ?" and vice versa find the NSnetwork associated with an STP by "? hasSTP A1" Again, this is an expediency for Rio and will be an issue we need to discuss for future topo database. I know some will object to this (someone *always* objects)...but this is sufficient for Rio and will allow us to put the focus back on NSI - not the cobbled together hacked up topology database. As always, what we do in the name of Rio should not be considered anything but a temporary/interim approach to be reviewed afterward and done better. Questions? Let me know. Thanks Jerry

1 0