[Nsi-wg] Please begin testing

Wed Nov 2 12:08:42 CDT 2011

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 at 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 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
>>>>
>>>
>>
>>
>
>

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