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