On 2012-06-27, at 11:48 PM, Jerry Sobieski wrote:
Hey John-
I concur with the justification for versioning, but I have several concerns with your proposed method:
Thank you. This was the general agreement in Oxford.
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.
Yes, I understand this point. I used the common NSI framework header as per the specification, and I defined an XML body similarly to the CS protocol specification. The versioning information exchanged is then the unique namespace identifying the XML version of the messaging interface definition.
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.
Hold on, I did not try to solve feature negotiation but interface versioning and capability description of those interfaces. I still must normalize a set of defined capabilities we would need described, but the generic schema is there in place. I view feature negotiation is out of scope for the interface discovery service. I am just trying to provide a simple mechanism to discover which versions of interfaces are available on an NSA.
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. )
Yes, that is the implication of the protocol and this simple interface discovery specification. I also thought about adding a more complex distributed interface discovery protocol, so that an NSA could discover the protocol versions and capabilities supported by all other NSA within the network, bit this would add an additional level of complexity I think is unneeded at this point. As to the issue of mixed versions within the network - yes you are correct - an NSA can have links with different version requirements. How this is handled should be left up to the local NSA and not the uRA. If an aggregator NSA receives an NSI request using CS protocol version 2, and this must be sent out to an NSA only supporting CS protocol version 1.SC, then it has three options: 1. Reformat the request to version 1.SC, instantiated a hybrid state machine capable of mapping between version 1 and 2 of the protocol, then send this to the 1.SC NSA. This will be somewhat painful, but will have to be done if both versions are to be supported. 2. Reject the version 2.0 request if it explicitly specifies a path that requires a 1.SC NSA to be traversed. A bit barbaric but always an option. 3. Re-route the request using a different NSA path which does support 2.0 and hope for the best. Having the uRA issue a message matching the version of all NSA along the tree is a no go. We can hope to have every deployed NSA support all versions of the protocol just so one older version NSA can be in the network is a bit overkill.
---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 do have a version ID in every NSI primitive to describe the version of the message being sent. We do however assume that the confirm, failed, and notification messages need to be returned in the version that the original request was sent.
---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.
No, we need to decouple version discovery from the Topology service, since the Topology service is one of the interfaces we need to discover versions for. This discovery mechanism is also removing the dependency of having all the interface protocol endpoints provisioned in topology data.
---We could have a separate version negotiation protocol... I think this is overkill at this time.
Hmm... dude.... this is what I have just defined and was agreed upon in Oxford. It is a simple mechanism that lets each NSA chose which version of the protocol to use with a peer based on what the peer describes it can support.
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.
It has been in the protocol since version 1.0, but in 2.0 I made it a specific field in the common NSI framework header.
Thoughts?
You just got them.
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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg