My responses are inline. Please note: If any issues require changes to the global topology description for the Rio interop test, please send those requested changes to me. I will review them and if appropriate change the topology file. This file will contain only NSI related inter-domain information and only as is necessary for Rio testing. We need to keep _/one/_ authoritative reference file for the global topology or the whole thing breaks. That reference file rests with me. I will post updates as necessary. If you require additional topology information specific to your implementation, you may append or modify this file at your own risk for your own use only. The base reference file takes precedence. On 9/7/11 10:34 PM, Atsuko Takefusa wrote:
Hi all,
May I confirm the descriptions of NSA and STP? It is really important to interoperate with the seven different implementations.
Which is the correct "stpId" description? #1 urn:ogf:network:stp:Aruba:A1 For STPs, #1 is the form agreed to in SLC and in the latest rev of the spec. For NSAids, the form: urn:ogf:network:NSnetwork:<netname> #3 other?
Which is the correct "requester/providerNSA" description? #1 urn:ogf:network:nsa:Aruba #2 urn:ogf:network:NSA:Aruba #3 urn:ogf:network:nsa:Aruba-OpenNSA #4 other? Ugh, after some investigation, I think we caused some problems with the topodb.
The NSAid is described in the spec as urn:ogf:network:NSnetwork:<NSnetworkid>. In the topo database, the NSA information is housed in an "NSA" object of the form urn:ogf:network:nsa:<NSAname>. And there is a separate "NSnetwork" object in the topo that gets the URN urn:ogf:network:NSnetwork:<NSnetworkid>. So this is rather backwards.. So my recommendation is this: where the spec says use the NSAid, we use the URN urn:ogf:network:NSnetwork:<NSnetworkid> - just as the spec says. Where the code needs to reach the NSA, the code will link first to the NSnetwork and from there to the NSA. I hope this sheds some light on things. JErry
In the John's mail, OpenDRAC returned: <requesterNSA>urn:ogf:network:nsa:ferb.surfnet.nl</requesterNSA> <providerNSA>urn:ogf:network:nsa:phineas.surfnet.nl</providerNSA> <sourceSTP> <stpId>urn:ogf:network:stp:Aruba:Aiden</stpId> </sourceSTP> <destSTP> <stpId>urn:ogf:network:stp:Aruba:Ashley</stpId> </destSTP> It will be modified at demo?
Thanks,
Atsuko
2011/9/8 Jerry Sobieski<jerry@nordu.net>:
Attendees- Jerry Sobieski (NORDUnet) Tomohiro Kudoh (AIST) Henrik Thostrup Jensen (NORDUnet) Jeroen van der Ham (UvA) Redek Krzywania (PSNC) Michal Balcerkiewicz (PSNC) John MacAuley (SURFnet)
Demo presentation at Venue
- We have 5 monitors and desks in the demo space at the art museum. We have a 90 minute formal demonstration presentation window Tuesday from 3:45pm to 5:15pm. The rest of the time we expect to have access to the demo room for continued testing. ***AI: Jerry: Confirm with RNP that the room will be available Wed and Thu after the window as well as leading up to the demonstration window.
- The implementation teams are asked to continue interop testing and to capture log files as they run the Plugfest Challenge tests. These log files can be annotated to show the protocol messaging. And these annotated logs can be presented at the venue in the demo room in addition to the live runs, and/or as part of a short PPT from each implementation team.
- We want to make sure we have as many live runs prepared for the demo window as is practical. But we do not expect all the Challenges to be ready or to be presented live. The anotated logs can be used to complement the live runs. We can allocate monitors as appropriate for the tests scenarios.
NSA Implementation Status I hope I summarized this close enough...
- OpenNSA (NORDUnet - Henrik) - mostly all functional, self interoperable (Chal #1 works) - encountering many interoperability issues within the MTL (WS* related issues) - some testing with dynamicKL, but encountered some SOAP issues not sure how to resolve. - Need some input from JM. - AutoBAHN - FUnctional, have had some issue in an office move(?) - Expect to begin interop testing very soon - Need updated topology - No WS issues experienced with dynKL - G-LAMBDA (AIST) - Almost ready for interop test... - some testing with G-LAMBDA KDDI Labs - authentication is an outstanding issue - DRAC - John is coding like a mad man.
*** Decided: For Rio, we will not require session authentication between NSAs. HTTP only. For SC we *will require* conformant authentication, HTTPS. *** For Rio, service authorization will be basic user based authorization. The user will be "jrv@internet2.edu". Case in-sensitive. This string my be authorized by the NSA however they wish, but all requests as part of the Plugfest will use this user credential. If the user is present, any/all service requests will be authorized. If not present, or any other user is present, service requests will be denied.
Topology
The current topology is the Rio Ring of 7 networks. Version 1.1c is latest. However, JM has proposed a modified topology to include "partOf" relations for STPs to indicate the NSnetwork object they belong to, and "managing" relation for NSA object to indicate which NSnetwork object they are responsible for. This version also uses full URN specification to name NSnetowork objects and STP objects.
***AI: Jerry: JS will review the topo file asap and if no other issue are obvious, it will be circulated as topo version 1.1d.
On 9/7/11 10:38 AM, Tomohiro Kudoh wrote:
This is a resending of test message:
Since the OGF NSI-WG mailing list is down, I made a temporary mailing list. Addresses on the Jerry's contact list are registered as well as Guy and Jeroen.
Tomohiro