[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