Peoples, While the discussion over opaqueness occurs on a separate thread I though I would communicate what I have done for the final version of the NSI CSv2. <xsd:complexType name="StpType"> <xsd:sequence> <xsd:element name="networkId" type="xsd:string" /> <xsd:element name="stpId" type="xsd:string" /> </xsd:sequence> </xsd:complexType> I defined a single string STP identifier as specified by Jeroen in his NSI-EXT documentation. I have also included a separate networkId in the request to allow for routing by network only. The only additional thought I have is to make the networkId optional so if at some point in the future we decide to allow parsing of the stpId for the networkId, the individual networkId field will no longer be required. John
On Tue, 10 Dec 2013, John MacAuley wrote:
While the discussion over opaqueness occurs on a separate thread I though I would communicate what I have done for the final version of the NSI CSv2.
<xsd:complexType name="StpType"> <xsd:sequence> <xsd:element name="networkId" type="xsd:string" /> <xsd:element name="stpId" type="xsd:string" /> </xsd:sequence> </xsd:complexType>
Mixing structural and string encoding (or whatever we call it). I am fine with either, but could we not do both.
I defined a single string STP identifier as specified by Jeroen in his NSI-EXT documentation.
I have also included a separate networkId in the request to allow for routing by network only.
It is not possible to do routing by network only in NML. The extra field does not do anything.
The only additional thought I have is to make the networkId optional so if at some point in the future we decide to allow parsing of the stpId for the networkId, the individual networkId field will no longer be required.
I am fine with just having a single stpId. AFAICT the solution above doesn't give us anything that the stpId doesn't. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
participants (2)
-
Henrik Thostrup Jensen
-
John MacAuley