[Nsi-wg] NSI protocol versioning and interface discovery

Jerry Sobieski jerry at nordu.net
Wed Jun 27 23:48:46 EDT 2012


Hey John-

I concur with the justification for versioning, but I have several 
concerns with your proposed method:

The NSI layer protocol itself should be self consistent without 
requiring SOAP or WSDLs or XML namespaces. - i.e. IF we want an NSA to 
recognize different versions of a peer NSA, we should specify this in 
the NSI layer - not SOAP to do this.   So the version identifier should 
be an explicit part of the NSI layer message - not the SOAP or some 
other implementation specific mechanism.

IMO, feature negotiation is a more complex task - you need to determine 
if feature negotiation is an available feature before you can use it to 
negotiate features:-)   And again, if these are NSI features, then NSI 
should negotiate them - not other underlying layers that do not have any 
insight into NSI functional comaptibilities.

Also, with versioning, an NSA will possibly have several versions it has 
to portray depending upon the segmentation it chose.   If we assume the 
highest common version is always used, we may find a single service tree 
builds in one version, but then a leaf node has an older version and all 
the parental NSAs in the service tree need to reprocess the request 
using an older version.  ...(I am not quite sure how this version 
selection should be handled.. but it is a problem we need to think 
through before deciding about feature negotiation. )

---IMO, the simplest way to do the versioning is to have a simple 
version ID in the NSI primitive message. Maybe attached to the Sending 
NSAID.  And a "incompatible version" error message if one of the NSAs 
cannot speak a compatible version.
---We could alternatively put the version identifier in the NSA topology 
object along with the CSproviderEndpoint. e.g. CSproviderVersion "2.0" 
or something.   This topology based versioning has the added benefit 
that an NSA can learn the version of a candidate path NSA *before* 
sending the first message and adjust its dialect accordingly.
---We could have a separate version negotiation protocol...   I think 
this is overkill at this time.

The NSI protocol layer should have its own explicit means of identifying 
the version of the primitive it just sent or received.  We really have 
to be careful to not link "NSI Features" to non-NSI layer implementation 
specifics.

Thoughts?
Jerry

On 6/27/12 3:49 PM, John MacAuley wrote:
> Peoples,
>
> I had hoped to get time in Delft to go over the new interface Discovery service but we ran out of time.  I have submitted the WSDL and supporting schema to the repository and attached a short slide package discussing the queryServices() operation.  Please have a look and provide comments.  If there are specific schema changes you would like to see please create an issue in code.google.com to track them.
>
> The new interface can be viewed @ http://code.google.com/p/ogf-nsi-project/source/browse/#svn%2Ftrunk
>
> Thank you,
> John.
>
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120627/00bb0809/attachment.html>


More information about the nsi-wg mailing list