[Nsi-wg] NSI Issues list – Rio de Janeiro Demo

Wed Sep 14 16:23:30 CDT 2011

Comments in line.

On 2011-09-14, at 12:37 PM, Radek Krzywania wrote:

> Hi,
> 1st of all - thank you all for the work. That was a great job and quite a success for spreading NSI awareness!
> 
> Now, back to work:
> This is stuff caught by Michal during implementation (some may repear with yours):
> - ConnectionStateType.TERMINATEING - maybe TERMINATING looks better

Got it.

> 
> - GenericAcknowledgmentType - should xxxConfirmed/Failed messages be sent before returning this type, or asynchronously? It could be removed as well

The acknowledgement should be returned at the point you have accepted the message for processing. The other messages come later (considerably later in some cases).

I validate the key attributes first just in case I need to send a fault message back instead of the ACK.  For example, on a reservation I verify the correlationId, replyTo, providerNSA, requesterNSA, and connectionId are present.  I also verify that the message is destined for me.  Once this is done I dispatch it for processing and return the ACK.  There is a small chance that the Confirmed/Failed beats the ACK back, but you should defensively code for that.

> 
> - queryConfirmed, queryFailed on provider interface - breaks consistency
> 
> - query on requester interface - breaks consistency

These were requested for error handling so that a providerNSA could query the requesterNSA to correlate schedule information after a restart.  Are people aware they can get a query across the requester NSA interface?

> 
> - maybe allow suggestion that either chain or tree reservation model is prefered in reservation request

This is an interesting feature.  Is it just a routing suggestion?

> 
> - reservation name is inconsistence with other method names (should be reserve, or change terminate to termination)

LOL - we argued the change to reservation when we were going to use provisionReservtion, terminateReservation, etc.  Then I thought the names were too long, so I shortened them and didn't think to change reservation back again.

> 
> - xxxConfirmed/Failed - all take some common parameters but wrapped into diffrent types, so more writing required instead of having one method to set this field, i.e.: 
> ReservationFailedRequestType reqFail = new ReservationFailedRequestType();
> reqFail.setCorrelationId(correlationId);
> reqFail.setReservationFailed(createFailed(conState, messageId, text));
> and
> ProvisionConfirmedRequestType reqConf = new ProvisionConfirmedRequestType();
> reqConf.setCorrelationId(correlationId);
> reqConf.setProvisionConfirmed(createConfirmed());
> in both cases (and it applies for other methods) ReservationFailedRequestType and ProvisionConfirmedRequestType same fields are carried, one common type would save writing 
> 

QueryFailedType is the exception.  I ended u wrapping the other ones so you know specifically the operation that failed via the failed name, but with the correlationId you could map it back to the original operation.  

> Now my two cents:
> 
> - We experienced from the demo, that sending a provision request just after reservation request, results in simple ack. So in fact we are unaware if the reservation is in auto provision state or not. We just get provisioned status update when reservation start time comes. We can wait 1 minute for that during demo, but if the service is about to start in 4 weeks...

Yes.  Functioning as defined.  I am concerned about this as well.  It causes complicated code (nothing to do with Web Services JERRY, but with the protocol).

> 
> - People were asking for query message, to retrieve the reservation status at all partners and a path.
> 
> - People were also interested if the same path will be configured for each provision message - protocol does not specify it, it’s actually up to domain, but in some cases it may be important (see Express scenario later)
> - Express was also interested in specyfing path for the reservation. E.g. they have one reservation now, and another in two months - two reservations needs to go the same path. We can't solve it now. Express also experienced issues with any connections they get - they need to tune it before use. Sa they do that about 2 weeks before operations, and check again about 1 day or hours before sending data. This scenario is a real user scenario, which we should discuss. I've invited the guy (apology - I forgot his name, but I will find him at the venue during break) from Express for the March OGF meeting in Oxford so we could discuss it.
> 
> 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: nsi-wg-bounces at ogf.org [mailto:nsi-wg-bounces at ogf.org] On Behalf
>> Of John MacAuley
>> Sent: Wednesday, September 14, 2011 4:46 PM
>> To: nsi-plugfest at m.aist.go.jp; nsi-wg at ogf.org WG
>> Subject: [Nsi-wg] NSI Issues list – Rio de Janeiro Demo
>> 
>> Peoples,
>> 
>> Here are some of the notes I captured.
>> 
>> The reservation XML message contains two element tags both named
>> “reservation”.  The first is the reservation operation and the second is the
>> reservation information contents.  This will need to be fixed in the types XSD.
>> 
>> The “providerNSA” and “requesterNSA” elements in the NSI protocol header
>> caused some confusion.  In the CS document we stated that this would be
>> populated with the NSnetwork URN as defined in Salt Lake City. However,
>> when the demo topology schema was created we introduced a new NSA
>> object.  Some people used the URN of the NSA object in the  “providerNSA”
>> and “requesterNSA” elements.  We will need to make a definitive statement
>> as we define the formal NSI topology.  Do we rename the elements to
>> “providerNSnetwork” and “requesterNSnetwork” and continue using the
>> NSnetwork URNs, or do we switch over to NSA URN?
>> 
>> Demo topology definition was an issue, but in the end we had something
>> workable for the demo.  Going forward we need to formalize NSI topology
>> definition and how it relates to other schema such as DTOX and NML.  I am
>> going to start working on the topology discovery/exchange problem to get use
>> moving forward.
>> 
>> Security presented interoperability issues as some people enforced
>> authentication and authorization while others did not.  Some systems could
>> not provide the needed credentials, and resulted in some incompatibility.  I
>> believe we are clear on what we want to implement for NSA-to-NSA security,
>> but we need to formalize the session security requirements so we can begin
>> to implement in the NSAs.
>> 
>> Namespace issues – this is not an issue with the protocol specification but with
>> a few of the less mature SOAP web services toolkits.  They get confused
>> between the interface and type namespaces for the protocol elements due to
>> the use of “ref” to reference protocol operation elements from the types XSD
>> in the interfaces WSDL.
>> 
>> Now that we have had some demo experience with error handling, I think it is
>> time to start formalizing values in the NsiExceptionType.  I have already
>> identified ten generic error conditions, and I am sure there are many more.
>> As a follow up to this item, NSA implementations need to populate the
>> NsiExceptionType.variables with additional information to help identify the
>> problem that caused the rejection of the message.  I had done this in
>> OpenDRAC so any errors returned to other NSA would contain information
>> formatted as follows:
>> 
>>    <messageId>SVC0001</messageId>
>>    <text>Invalid or missing parameter</text>
>>    <variables>
>>        <Attribute Name="replyTo"
>> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
>>            <AttributeValue xsi:type="xs:string"
>> xmlns:xs="http://www.w3.org/2001/XMLSchema"
>>                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> &lt;null&gt;</AttributeValue>
>>        </Attribute>
>>    </variables>
>> 
>> Interface version discovery – I had discussed this with the group previously,
>> but now that we are moving forward, up issuing NSI schema versions, and
>> adding new interfaces we will need a mechanism for discovering the
>> interfaces and versions supported by an NSA.  I will propose something formal
>> when I get a chance.
>> 
>> John.
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nsi-wg
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110914/45ea0991/attachment-0001.html 