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
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 #2 urn:ogf:network:STP:Aruba:A1 #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? 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
-- Atsuko Takefusa, Ph. D. Information Technology Research Institute, AIST
For the STP I prefer lowercase.
#1 urn:ogf:network:stp:Aruba:A1
This is the correct nsa for Aruba.
#3 urn:ogf:network:nsa:Aruba-OpenNSA
In the John's mail, OpenDRAC returned:
Sorry this was my mistake as I returned their real names instead of the pretend ones for the demo. These were hardcoded in a test program. John. On 2011-09-07, at 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 #2 urn:ogf:network:STP:Aruba:A1 #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?
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
-- Atsuko Takefusa, Ph. D. Information Technology Research Institute, AIST _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Hi John, Jerry, I would like to confirm decisions. - We will use http and we will *NOT* use session authentication. That is, there is no username/password for http sessions. - We will use username in the NSI message attribute. The username should be "jrv@internet2.edu" (non case sensitive) Are these ok? Tomohiro On Wed, 7 Sep 2011 22:42:00 -0400 John MacAuley <john.macauley@surfnet.nl> wrote:
For the STP I prefer lowercase.
#1 urn:ogf:network:stp:Aruba:A1
This is the correct nsa for Aruba.
#3 urn:ogf:network:nsa:Aruba-OpenNSA
In the John's mail, OpenDRAC returned:
Sorry this was my mistake as I returned their real names instead of the pretend ones for the demo. These were hardcoded in a test program.
John.
On 2011-09-07, at 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 #2 urn:ogf:network:STP:Aruba:A1 #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?
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
-- Atsuko Takefusa, Ph. D. Information Technology Research Institute, AIST _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
We agreed that the NSA with authenticate using http basic authentication. The user credentials are in the NSI message. Sent from my iPhone On 2011-09-08, at 2:55 AM, Tomohiro Kudoh <t.kudoh@aist.go.jp> wrote:
Hi John, Jerry,
I would like to confirm decisions.
- We will use http and we will *NOT* use session authentication. That is, there is no username/password for http sessions.
- We will use username in the NSI message attribute. The username should be "jrv@internet2.edu" (non case sensitive)
Are these ok?
Tomohiro
On Wed, 7 Sep 2011 22:42:00 -0400 John MacAuley <john.macauley@surfnet.nl> wrote:
For the STP I prefer lowercase.
#1 urn:ogf:network:stp:Aruba:A1
This is the correct nsa for Aruba.
#3 urn:ogf:network:nsa:Aruba-OpenNSA
In the John's mail, OpenDRAC returned:
Sorry this was my mistake as I returned their real names instead of the pretend ones for the demo. These were hardcoded in a test program.
John.
On 2011-09-07, at 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 #2 urn:ogf:network:STP:Aruba:A1 #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?
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
-- Atsuko Takefusa, Ph. D. Information Technology Research Institute, AIST _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
John, If so, what is the password? Also, it will be not easy to make username case in-sensitive. Tomohiro 2011/9/8 John MacAuley <john.macauley@surfnet.nl>:
We agreed that the NSA with authenticate using http basic authentication. The user credentials are in the NSI message.
Sent from my iPhone
On 2011-09-08, at 2:55 AM, Tomohiro Kudoh <t.kudoh@aist.go.jp> wrote:
Hi John, Jerry,
I would like to confirm decisions.
- We will use http and we will *NOT* use session authentication. That is, there is no username/password for http sessions.
- We will use username in the NSI message attribute. The username should be "jrv@internet2.edu" (non case sensitive)
Are these ok?
Tomohiro
On Wed, 7 Sep 2011 22:42:00 -0400 John MacAuley <john.macauley@surfnet.nl> wrote:
For the STP I prefer lowercase.
#1 urn:ogf:network:stp:Aruba:A1
This is the correct nsa for Aruba.
#3 urn:ogf:network:nsa:Aruba-OpenNSA
In the John's mail, OpenDRAC returned:
Sorry this was my mistake as I returned their real names instead of the pretend ones for the demo. These were hardcoded in a test program.
John.
On 2011-09-07, at 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 #2 urn:ogf:network:STP:Aruba:A1 #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?
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
-- Atsuko Takefusa, Ph. D. Information Technology Research Institute, AIST _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
For HTTP BASIC authentication we will use the following credentials. I believe this should pass most complex password rules... userId: nsidemo password: RioPlug-Fest2011! If there are any issues let me know. John. On 2011-09-08, at 8:20 AM, Tomohiro Kudoh wrote:
John,
If so, what is the password?
Also, it will be not easy to make username case in-sensitive.
Tomohiro
2011/9/8 John MacAuley <john.macauley@surfnet.nl>:
We agreed that the NSA with authenticate using http basic authentication. The user credentials are in the NSI message.
Sent from my iPhone
On 2011-09-08, at 2:55 AM, Tomohiro Kudoh <t.kudoh@aist.go.jp> wrote:
Hi John, Jerry,
I would like to confirm decisions.
- We will use http and we will *NOT* use session authentication. That is, there is no username/password for http sessions.
- We will use username in the NSI message attribute. The username should be "jrv@internet2.edu" (non case sensitive)
Are these ok?
Tomohiro
On Wed, 7 Sep 2011 22:42:00 -0400 John MacAuley <john.macauley@surfnet.nl> wrote:
For the STP I prefer lowercase.
#1 urn:ogf:network:stp:Aruba:A1
This is the correct nsa for Aruba.
#3 urn:ogf:network:nsa:Aruba-OpenNSA
In the John's mail, OpenDRAC returned:
Sorry this was my mistake as I returned their real names instead of the pretend ones for the demo. These were hardcoded in a test program.
John.
On 2011-09-07, at 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 #2 urn:ogf:network:STP:Aruba:A1 #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?
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
-- Atsuko Takefusa, Ph. D. Information Technology Research Institute, AIST _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
John Ok. This is the information we have been looking for. Thanks, Tomohiro 2011/9/8 John MacAuley <john.macauley@surfnet.nl>:
For HTTP BASIC authentication we will use the following credentials. I believe this should pass most complex password rules...
userId: nsidemo password: RioPlug-Fest2011!
If there are any issues let me know.
John.
On 2011-09-08, at 8:20 AM, Tomohiro Kudoh wrote:
John,
If so, what is the password?
Also, it will be not easy to make username case in-sensitive.
Tomohiro
2011/9/8 John MacAuley <john.macauley@surfnet.nl>:
We agreed that the NSA with authenticate using http basic authentication. The user credentials are in the NSI message.
Sent from my iPhone
On 2011-09-08, at 2:55 AM, Tomohiro Kudoh <t.kudoh@aist.go.jp> wrote:
Hi John, Jerry,
I would like to confirm decisions.
- We will use http and we will *NOT* use session authentication. That is, there is no username/password for http sessions.
- We will use username in the NSI message attribute. The username should be "jrv@internet2.edu" (non case sensitive)
Are these ok?
Tomohiro
On Wed, 7 Sep 2011 22:42:00 -0400 John MacAuley <john.macauley@surfnet.nl> wrote:
For the STP I prefer lowercase.
#1 urn:ogf:network:stp:Aruba:A1
This is the correct nsa for Aruba.
#3 urn:ogf:network:nsa:Aruba-OpenNSA
In the John's mail, OpenDRAC returned:
Sorry this was my mistake as I returned their real names instead of the pretend ones for the demo. These were hardcoded in a test program.
John.
On 2011-09-07, at 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 #2 urn:ogf:network:STP:Aruba:A1 #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?
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 > >
-- Atsuko Takefusa, Ph. D. Information Technology Research Institute, AIST _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
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
participants (4)
-
Atsuko Takefusa -
Jerry Sobieski -
John MacAuley -
Tomohiro Kudoh