Hi all, I also agree with Tomohiro and Radek. HTTPS issue is critical for demo. When it does not work, we can't show both control and data plane demonstration. We should spend our time for interoperability of SC WSDL, data plane connections, and visualization. We have only less than two weeks. Best regards, Takahiro On 2011/11/02 17:18, Radek Krzywania wrote:

Hi, I agree with Tomohiro. We spent a lot of time fighting with dataplane for FIA demo, instead of working with NSI protocol itself. We still do not have HTTPS and can’t talk with DRAC at NetherLight, who is direct peer and GEANT related NRENS way to US and Japan. It's critical for us. I would appreciate if for SC demo we could use HTTP mode as well.

Best regards Radek

________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________

...

-----Original Message----- From: Tomohiro Kudoh [mailto:t.kudoh@aist.go.jp] Sent: Wednesday, November 02, 2011 5:36 AM To: Jerry Sobieski Cc: t.kudoh@aist.go.jp; nsi-plugfest@m.aist.go.jp; automatedgole- pilot@internet2.edu; nsi-wg@ogf.org Subject: Re: [Nsi-wg] Please begin testing

Hi Jerry,

Again, I think not all the NSA should support https, but only aggregaters are required to do so.

Considering the time we have before SC, making https madatory may have too much risk for success of SC demonstration.

Tomohiro

On Wed, 02 Nov 2011 00:12:44 -0400 Jerry Sobieski<jerry@nordu.net> wrote:

...

Hi all-

I just circulated the most recent global NSI topology for the Supercomputing demos.

It is now time to begin testing again. Please get started asap, and monitor the nsi-wg chat room on Skype.

For those of you with uRA clients that do not perform any segmentation, please select an aggregator NSA and begin testing to that network NSA.

For the Aggregator NSAs, please verify that you are able to interop with each other implementation, then to each network. start with your direct data plane neighbors and work your way outward. (TK: do you have some thoughts on this verification process...?)

I think the key issues we need to work thru are a) HTTPS interop, b) SC WSDL consistency, c) Query result consistency, and then just coordination among the whole group so we do not get too many requests interfering with one another. All NSI implementations should be able to successfully talk to all the other implementations by now with all primitives.

If we need additional VLANs, let me know and I can add more to the topology.

We will want to develop a looping script at some point this week or early next. This script will issues a sequence of Reservation Requests and walk the connection(s) through their lifecycle while the viz tools track the state transitions. _/This will be the fundamental demo during the conference. /_ We probably need some simple orchestration tools: An end system daemon that will configure an particular IPaddr on the VLAN subinterface when a connection is provisioned and then issue/respond to pings. Any idle hands out there want to work on some code?

Thanks! Jerry

_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg

-- Takahiro Miyamoto <tk-miyamoto@kddilabs.jp> KDDI R&D Laboratories, Inc. TEL: +81-49-278-7455 / FAX: +81-49-278-7811

Hi All- I did not mean to imply everyone had to implement an HTTPS interface - I just meant the issue needs to be resolved and the solution tested. The Spec says "authenticated and secure" - but it does not require HTTPS. So we are in grey area. For the SC demo we will do the following: 1- The Aggregator NSAs *should* implement both HTTPS and HTTP transports for their RA. This will allow them to segment requests to either type of PA. The aggregator NSAs are G-LAMBDA-A, AutoBAHN, and OpenNSA. (OpenNSA plans to implement both modes for the RA for the SC demo...but will be close. TK: What about GL-A? RK: Is this possible for AB prior to SC? 2- For the SC demo, PAs can do either HTTP or HTTPS. The RA client must be able to conform to the PA they intend to interact with. If your client RA is HTTP only, and it wants to interact with a HTTPS only PA, it can forward its primitive request to an HTTP Aggregator PA which will "segment" the request and send it to the HTTPS PA. This adds one layer to the service tree, but is otherwise is a fully compliant property of the protocol. Does this help resolve the problem? Jerry On 11/2/11 4:18 AM, Radek Krzywania wrote:

Hi, I agree with Tomohiro. We spent a lot of time fighting with dataplane for FIA demo, instead of working with NSI protocol itself. We still do not have HTTPS and can’t talk with DRAC at NetherLight, who is direct peer and GEANT related NRENS way to US and Japan. It's critical for us. I would appreciate if for SC demo we could use HTTP mode as well.

Best regards Radek

________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________

...

-----Original Message----- From: Tomohiro Kudoh [mailto:t.kudoh@aist.go.jp] Sent: Wednesday, November 02, 2011 5:36 AM To: Jerry Sobieski Cc: t.kudoh@aist.go.jp; nsi-plugfest@m.aist.go.jp; automatedgole- pilot@internet2.edu; nsi-wg@ogf.org Subject: Re: [Nsi-wg] Please begin testing

Hi Jerry,

Again, I think not all the NSA should support https, but only aggregaters are required to do so.

Considering the time we have before SC, making https madatory may have too much risk for success of SC demonstration.

Tomohiro

On Wed, 02 Nov 2011 00:12:44 -0400 Jerry Sobieski<jerry@nordu.net> wrote:

...

Hi all-

I just circulated the most recent global NSI topology for the Supercomputing demos.

It is now time to begin testing again. Please get started asap, and monitor the nsi-wg chat room on Skype.

For those of you with uRA clients that do not perform any segmentation, please select an aggregator NSA and begin testing to that network NSA.

For the Aggregator NSAs, please verify that you are able to interop with each other implementation, then to each network. start with your direct data plane neighbors and work your way outward. (TK: do you have some thoughts on this verification process...?)

I think the key issues we need to work thru are a) HTTPS interop, b) SC WSDL consistency, c) Query result consistency, and then just coordination among the whole group so we do not get too many requests interfering with one another. All NSI implementations should be able to successfully talk to all the other implementations by now with all primitives.

If we need additional VLANs, let me know and I can add more to the topology. We will want to develop a looping script at some point this week or early next. This script will issues a sequence of Reservation Requests and walk the connection(s) through their lifecycle while the viz tools track the state transitions. _/This will be the fundamental demo during the conference. /_ We probably need some simple orchestration tools: An end system daemon that will configure an particular IPaddr on the VLAN subinterface when a connection is provisioned and then issue/respond to pings. Any idle hands out there want to work on some code?

Thanks! Jerry

I just need HTTPS. I am not authenticating the client. I will send back to the endpoint in the format requested in the replyTo field. John. On 2011-11-02, at 9:52 AM, Tomohiro Kudoh wrote:

So, John, could you please clarify how https should be supported by aggregators?

- Do you need just https (SSL/TLS)? Or, is client authentication required?

- As a providerNSA, can you use http to send back confirm/fail message to a requester?

Tomohiro

2011/11/2 Jerry Sobieski <jerry@nordu.net>:

...

Hi All-

I did not mean to imply everyone had to implement an HTTPS interface - I just meant the issue needs to be resolved and the solution tested.

The Spec says "authenticated and secure" - but it does not require HTTPS. So we are in grey area. For the SC demo we will do the following:

1- The Aggregator NSAs *should* implement both HTTPS and HTTP transports for their RA. This will allow them to segment requests to either type of PA. The aggregator NSAs are G-LAMBDA-A, AutoBAHN, and OpenNSA. (OpenNSA plans to implement both modes for the RA for the SC demo...but will be close. TK: What about GL-A? RK: Is this possible for AB prior to SC?

2- For the SC demo, PAs can do either HTTP or HTTPS. The RA client must be able to conform to the PA they intend to interact with.

If your client RA is HTTP only, and it wants to interact with a HTTPS only PA, it can forward its primitive request to an HTTP Aggregator PA which will "segment" the request and send it to the HTTPS PA. This adds one layer to the service tree, but is otherwise is a fully compliant property of the protocol.

Does this help resolve the problem? Jerry

On 11/2/11 4:18 AM, Radek Krzywania wrote:

...

Hi, I agree with Tomohiro. We spent a lot of time fighting with dataplane for FIA demo, instead of working with NSI protocol itself. We still do not have HTTPS and can’t talk with DRAC at NetherLight, who is direct peer and GEANT related NRENS way to US and Japan. It's critical for us. I would appreciate if for SC demo we could use HTTP mode as well.

Best regards Radek

________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________

...

-----Original Message----- From: Tomohiro Kudoh [mailto:t.kudoh@aist.go.jp] Sent: Wednesday, November 02, 2011 5:36 AM To: Jerry Sobieski Cc: t.kudoh@aist.go.jp; nsi-plugfest@m.aist.go.jp; automatedgole- pilot@internet2.edu; nsi-wg@ogf.org Subject: Re: [Nsi-wg] Please begin testing

Hi Jerry,

Again, I think not all the NSA should support https, but only aggregaters are required to do so.

Considering the time we have before SC, making https madatory may have too much risk for success of SC demonstration.

Tomohiro

On Wed, 02 Nov 2011 00:12:44 -0400 Jerry Sobieski<jerry@nordu.net> wrote:

...

Hi all-

I just circulated the most recent global NSI topology for the Supercomputing demos.

It is now time to begin testing again. Please get started asap, and monitor the nsi-wg chat room on Skype.

For those of you with uRA clients that do not perform any segmentation, please select an aggregator NSA and begin testing to that network NSA.

For the Aggregator NSAs, please verify that you are able to interop with each other implementation, then to each network. start with your direct data plane neighbors and work your way outward. (TK: do you have some thoughts on this verification process...?)

I think the key issues we need to work thru are a) HTTPS interop, b) SC WSDL consistency, c) Query result consistency, and then just coordination among the whole group so we do not get too many requests interfering with one another. All NSI implementations should be able to successfully talk to all the other implementations by now with all primitives.

If we need additional VLANs, let me know and I can add more to the

topology.

...

We will want to develop a looping script at some point this week or early next. This script will issues a sequence of Reservation Requests and walk the connection(s) through their lifecycle while the viz tools track the state transitions. _/This will be the fundamental demo during the conference. /_ We probably need some simple orchestration tools: An end system

daemon

...

that will configure an particular IPaddr on the VLAN subinterface when a connection is provisioned and then issue/respond to pings. Any idle hands out there want to work on some code?

Thanks! Jerry

Tomohiro, I have a demo Friday afternoon so the earliest I could start testing is Saturday. If I assume your team is taking the weekend off (as they should) then the earliest would be Sunday night or Monday morning my time. Let me know if this is good for you. John. On 2011-11-02, at 1:08 PM, Tomohiro Kudoh wrote:

Hi John,

Thank you. This will be doable.

Is it possible to test interoperability with your providerNSA?

(Thursday is a national holiday in Japan, so aist would like to test on Friday (your late Thursday) if possible)

Tomohiro

2011/11/2 John MacAuley <john.macauley@surfnet.nl>:

...

I just need HTTPS. I am not authenticating the client.

I will send back to the endpoint in the format requested in the replyTo field.

John.

On 2011-11-02, at 9:52 AM, Tomohiro Kudoh wrote:

...

So, John, could you please clarify how https should be supported by aggregators?

- Do you need just https (SSL/TLS)? Or, is client authentication required?

- As a providerNSA, can you use http to send back confirm/fail message to a requester?

Tomohiro

2011/11/2 Jerry Sobieski <jerry@nordu.net>:

...

Hi All-

I did not mean to imply everyone had to implement an HTTPS interface - I just meant the issue needs to be resolved and the solution tested.

The Spec says "authenticated and secure" - but it does not require HTTPS. So we are in grey area. For the SC demo we will do the following:

1- The Aggregator NSAs *should* implement both HTTPS and HTTP transports for their RA. This will allow them to segment requests to either type of PA. The aggregator NSAs are G-LAMBDA-A, AutoBAHN, and OpenNSA. (OpenNSA plans to implement both modes for the RA for the SC demo...but will be close. TK: What about GL-A? RK: Is this possible for AB prior to SC?

2- For the SC demo, PAs can do either HTTP or HTTPS. The RA client must be able to conform to the PA they intend to interact with.

If your client RA is HTTP only, and it wants to interact with a HTTPS only PA, it can forward its primitive request to an HTTP Aggregator PA which will "segment" the request and send it to the HTTPS PA. This adds one layer to the service tree, but is otherwise is a fully compliant property of the protocol.

Does this help resolve the problem? Jerry

On 11/2/11 4:18 AM, Radek Krzywania wrote:

...

Hi, I agree with Tomohiro. We spent a lot of time fighting with dataplane for FIA demo, instead of working with NSI protocol itself. We still do not have HTTPS and can’t talk with DRAC at NetherLight, who is direct peer and GEANT related NRENS way to US and Japan. It's critical for us. I would appreciate if for SC demo we could use HTTP mode as well.

Best regards Radek

________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________

...

-----Original Message----- From: Tomohiro Kudoh [mailto:t.kudoh@aist.go.jp] Sent: Wednesday, November 02, 2011 5:36 AM To: Jerry Sobieski Cc: t.kudoh@aist.go.jp; nsi-plugfest@m.aist.go.jp; automatedgole- pilot@internet2.edu; nsi-wg@ogf.org Subject: Re: [Nsi-wg] Please begin testing

Hi Jerry,

Again, I think not all the NSA should support https, but only aggregaters are required to do so.

Considering the time we have before SC, making https madatory may have too much risk for success of SC demonstration.

Tomohiro

On Wed, 02 Nov 2011 00:12:44 -0400 Jerry Sobieski<jerry@nordu.net> wrote:

> Hi all- > > I just circulated the most recent global NSI topology for the > Supercomputing demos. > > It is now time to begin testing again. Please get started asap, and > monitor the nsi-wg chat room on Skype. > > For those of you with uRA clients that do not perform any segmentation, > please select an aggregator NSA and begin testing to that network NSA. > > For the Aggregator NSAs, please verify that you are able to interop with > each other implementation, then to each network. start with your direct > data plane neighbors and work your way outward. (TK: do you have some > thoughts on this verification process...?) > > I think the key issues we need to work thru are a) HTTPS interop, b) SC > WSDL consistency, c) Query result consistency, and then just > coordination among the whole group so we do not get too many requests > interfering with one another. All NSI implementations should be able > to successfully talk to all the other implementations by now with all > primitives. > > If we need additional VLANs, let me know and I can add more to the

topology. > > We will want to develop a looping script at some point this week or > early next. This script will issues a sequence of Reservation Requests > and walk the connection(s) through their lifecycle while the viz tools > track the state transitions. _/This will be the fundamental demo during > the conference. > /_ > We probably need some simple orchestration tools: An end system

daemon > > that will configure an particular IPaddr on the VLAN subinterface when > a connection is provisioned and then issue/respond to pings. Any idle > hands out there want to work on some code? > > Thanks! > Jerry

-- 工藤知宏 t.kudoh@aist.go.jp 独立行政法人 産業技術総合研究所 情報技術研究部門 インフラウェア研究グループ 〒305-8568 茨城県つくば市梅園1-1-1中央第二 Phone:029-861-5761 Fax:029-862-6601