[Nsi-wg] Please begin testing

[Tomohiro Kudoh]

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 at 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 at man.poznan.pl                   Networking Center
>> +48 61 850 25 26                             http://www.man.poznan.pl
>> ________________________________________________________________________
>>
>>
>>> -----Original Message-----
>>> From: Tomohiro Kudoh [mailto:t.kudoh at aist.go.jp]
>>> Sent: Wednesday, November 02, 2011 5:36 AM
>>> To: Jerry Sobieski
>>> Cc: t.kudoh at aist.go.jp; nsi-plugfest at m.aist.go.jp; automatedgole-
>>> pilot at internet2.edu; nsi-wg at 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 at 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
>>
>