NSI WSDL - The Maastricht Updates
Peoples, I believe I have completed all the WSDL changes agreed to in Maastricht. Please download the WSDL and verify this new version. I have also added a xsd-docs.zip file to the repository that contains a set of HTML based documentation. In addition, I have restructured the svn repository by service and submitted a draft version of the topology XSD for Jereon. John
Hi, On 11 Jun 2013, at 15:34, John MacAuley <john.macauley@surfnet.nl> wrote:
In addition, I have restructured the svn repository by service and submitted a draft version of the topology XSD for Jereon.
I've committed the sources and schemas that are also in the Topology Representation doc. Jeroen.
Hi John, Thank you very much for the WSDL update. I have checked them and thought that one thing should be modified as follows: ogf_nsi_connection_types_v2_0.xsd, line 735, <xsd:element name="path" type="tns:PathType" minOccurs="0" /> --> <xsd:element name="path" type="tns:PathType"/> I think "path" in ReservationRequestCriteriaType is a mandatory parameter. -- <xsd:complexType name="ReservationRequestCriteriaType"> <xsd:annotation>.....</xsd:annotation> <xsd:sequence> <xsd:element name="schedule" type="tns:ScheduleType" minOccurs="0" /> <xsd:element name="bandwidth" type="xsd:int" minOccurs="0" /> <xsd:element name="serviceAttributes" type="ftypes:TypeValuePairListType" minOccurs="0" /> <xsd:element name="path" type="tns:PathType" minOccurs="0" /> </xsd:sequence> <xsd:attribute name="version" type="xsd:int" use="optional" /> </xsd:complexType> -- Thanks, Atsuko 2013/6/11 John MacAuley <john.macauley@surfnet.nl>:
Peoples,
I believe I have completed all the WSDL changes agreed to in Maastricht. Please download the WSDL and verify this new version. I have also added a xsd-docs.zip file to the repository that contains a set of HTML based documentation.
In addition, I have restructured the svn repository by service and submitted a draft version of the topology XSD for Jereon.
John _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
On Tue, 18 Jun 2013, Atsuko Takefusa wrote:
I think "path" in ReservationRequestCriteriaType is a mandatory parameter.
I agree. Further: For ReservationRequestCriteriaType I think schedule, bandwidth and path should be mandatory. For ReservationConfirmCriteriaType serviceAttributes should be optional. In fact, except for the version attribute (which is optional in one, and mandatory in another), ReservationRequestCriteriaType and ReservationConfirmCriteriaType appear to be the same. We could consider moving version out of these use a single type. Afterall, both describe a connection. Possibly use complexContent instead, but that actually leaves more types. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Here is the reason you are seeing these attributes as optional: The modify command was folded into the reserve command, and therefore, must now share the same types. It does make the XSD a little less intuitive, and documentation must be read to understand what parameters are required during the initial reserve versus a subsequent modification. John On 2013-06-18, at 8:06 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
On Tue, 18 Jun 2013, Atsuko Takefusa wrote:
I think "path" in ReservationRequestCriteriaType is a mandatory parameter.
I agree. Further:
For ReservationRequestCriteriaType
I think schedule, bandwidth and path should be mandatory.
For ReservationConfirmCriteriaType
serviceAttributes should be optional.
In fact, except for the version attribute (which is optional in one, and mandatory in another), ReservationRequestCriteriaType and ReservationConfirmCriteriaType appear to be the same.
We could consider moving version out of these use a single type. Afterall, both describe a connection. Possibly use complexContent instead, but that actually leaves more types.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
I understand the reason that RA will input "schedule" and/or "bandwidth" in a modify command. Thanks, Atsuko 2013/6/19 John MacAuley <john.macauley@surfnet.nl>:
Here is the reason you are seeing these attributes as optional: The modify command was folded into the reserve command, and therefore, must now share the same types. It does make the XSD a little less intuitive, and documentation must be read to understand what parameters are required during the initial reserve versus a subsequent modification.
John
On 2013-06-18, at 8:06 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
On Tue, 18 Jun 2013, Atsuko Takefusa wrote:
I think "path" in ReservationRequestCriteriaType is a mandatory parameter.
I agree. Further:
For ReservationRequestCriteriaType
I think schedule, bandwidth and path should be mandatory.
For ReservationConfirmCriteriaType
serviceAttributes should be optional.
In fact, except for the version attribute (which is optional in one, and mandatory in another), ReservationRequestCriteriaType and ReservationConfirmCriteriaType appear to be the same.
We could consider moving version out of these use a single type. Afterall, both describe a connection. Possibly use complexContent instead, but that actually leaves more types.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
On Tue, 18 Jun 2013, John MacAuley wrote:
Here is the reason you are seeing these attributes as optional: The modify command was folded into the reserve command, and therefore, must now share the same types.
Thanks. Makes sense. However, with that in mind I think the seperation between ReservationRequestCriteriaType and ReservationConfirmCriteriaType makes evene less sense. They carry the same data, and there will always need to be some sanity checking outside the xml-xsd correlation anyway. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Peoples, To follow up with the simplification I mentioned on the call today I have pulled together two example reserve requests. Here is the current structure with dedicated bandwidth and path attributes in the criteria element. <tns:reserve xmlns:tns="http://schemas.ogf.org/nsi/2013/04/connection/types" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <connectionId>urn:uuid:4b4a71d0-3c71-47cf-a646-beacb14a4c72</connectionId> <globalReservationId>urn:uuid:83fe4f36-5b38-41b6-bc46-a362a06a54ee</globalReservationId> <description></description> <criteria version="1"> <schedule> <startTime>2013-09-30T09:30:10Z</startTime> <endTime>2013-09-30T10:30:10Z</endTime> </schedule> <bandwidth>1000</bandwidth> <serviceAttributes> <attribute type="sNCP" targetNamespace="http://schemas.surfnet.nl/nsi/2013/04/services"> <value>Protected</value> </attribute> <attribute> <surf:sNCP xmlns:surf="http://schemas.surfnet.nl/nsi/2013/04/services">Protected</surf:sNCP> </attribute> </serviceAttributes> <path> <directionality>Bidirectional</directionality> <symmetricPath>true</symmetricPath> <sourceSTP> <networkId>urn:ogf:network:netherlight.net:2012</networkId> <localId>uvalight-netherlight</localId> </sourceSTP> <destSTP> <networkId>urn:ogf:network:netherlight.net:2012</networkId> <localId>netherlight-czechlight</localId> </destSTP> </path> </criteria> </tns:reserve> Notice the service attributes provided. This is an example of the two ways we can specify the same thing, and in this case, it is the SURFnet subnetwork protection attribute. I would like to flatten the serviceAttributes structure to a simple ANY to give us the following: <serviceAttributes> <surf:sNCP xmlns:surf="http://schemas.surfnet.nl/nsi/2013/04/services">Protected</surf:sNCP> </serviceAttributes> Now onto the key point I was trying to get across. Bandwidth and path are specific to a symmetric point-to-point service. I would like to make a simple change to move bandwidth and path into serviceAttributes with their own specific p2pservice namespace. This will let us have a more generic reserve message. Here is an example: <tns:reserve xmlns:tns="http://schemas.ogf.org/nsi/2013/04/connection/types" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <connectionId>urn:uuid:4b4a71d0-3c71-47cf-a646-beacb14a4c72</connectionId> <globalReservationId>urn:uuid:83fe4f36-5b38-41b6-bc46-a362a06a54ee</globalReservationId> <description></description> <criteria version="1"> <schedule> <startTime>2013-09-30T09:30:10Z</startTime> <endTime>2013-09-30T10:30:10Z</endTime> </schedule> <serviceAttributes> <p2p:bandwidth xmlns:p2p="http://schemas.ogf.org/nsi/2013/04/connection/p2pservice">1000</p2p:bandwidth> <p2p:path xmlns:p2p="http://schemas.ogf.org/nsi/2013/04/connection/p2pservice"> <directionality>Bidirectional</directionality> <symmetricPath>true</symmetricPath> <sourceSTP> <networkId>urn:ogf:network:netherlight.net:2012</networkId> <localId>uvalight-netherlight</localId> </sourceSTP> <destSTP> <networkId>urn:ogf:network:netherlight.net:2012</networkId> <localId>netherlight-czechlight</localId> </destSTP> </p2p:path> <surf:sNCP xmlns:surf="http://schemas.surfnet.nl/nsi/2013/04/services">Protected</surf:sNCP> </serviceAttributes> </criteria> </tns:reserve> This will allow us to use the existing XSD for new service definitions without needing to modify the schema. New attributes can be imported for other namespaces when defined. It really is a simple change and it should provide good value. Comments? John On 2013-06-19, at 9:51 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
On Tue, 18 Jun 2013, John MacAuley wrote:
Here is the reason you are seeing these attributes as optional: The modify command was folded into the reserve command, and therefore, must now share the same types.
Thanks. Makes sense.
However, with that in mind I think the seperation between ReservationRequestCriteriaType and ReservationConfirmCriteriaType makes evene less sense. They carry the same data, and there will always need to be some sanity checking outside the xml-xsd correlation anyway.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi, As long as we're being verbose, I would suggest to add a "unit" attribute to the bandwidth to make sure that everyone understands that this is in megabits. Jeroen. On 20 Jun 2013, at 05:49, John MacAuley <john.macauley@surfnet.nl> wrote:
Peoples,
To follow up with the simplification I mentioned on the call today I have pulled together two example reserve requests. Here is the current structure with dedicated bandwidth and path attributes in the criteria element.
<tns:reserve xmlns:tns="http://schemas.ogf.org/nsi/2013/04/connection/types" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<connectionId>urn:uuid:4b4a71d0-3c71-47cf-a646-beacb14a4c72</connectionId> <globalReservationId>urn:uuid:83fe4f36-5b38-41b6-bc46-a362a06a54ee</globalReservationId> <description></description> <criteria version="1"> <schedule> <startTime>2013-09-30T09:30:10Z</startTime> <endTime>2013-09-30T10:30:10Z</endTime> </schedule> <bandwidth>1000</bandwidth> <serviceAttributes> <attribute type="sNCP" targetNamespace="http://schemas.surfnet.nl/nsi/2013/04/services"> <value>Protected</value> </attribute> <attribute> <surf:sNCP xmlns:surf="http://schemas.surfnet.nl/nsi/2013/04/services">Protected</surf:sNCP> </attribute> </serviceAttributes> <path> <directionality>Bidirectional</directionality> <symmetricPath>true</symmetricPath> <sourceSTP> <networkId>urn:ogf:network:netherlight.net:2012</networkId> <localId>uvalight-netherlight</localId> </sourceSTP> <destSTP> <networkId>urn:ogf:network:netherlight.net:2012</networkId> <localId>netherlight-czechlight</localId> </destSTP> </path> </criteria> </tns:reserve>
Notice the service attributes provided. This is an example of the two ways we can specify the same thing, and in this case, it is the SURFnet subnetwork protection attribute. I would like to flatten the serviceAttributes structure to a simple ANY to give us the following:
<serviceAttributes> <surf:sNCP xmlns:surf="http://schemas.surfnet.nl/nsi/2013/04/services">Protected</surf:sNCP> </serviceAttributes>
Now onto the key point I was trying to get across. Bandwidth and path are specific to a symmetric point-to-point service. I would like to make a simple change to move bandwidth and path into serviceAttributes with their own specific p2pservice namespace. This will let us have a more generic reserve message. Here is an example:
<tns:reserve xmlns:tns="http://schemas.ogf.org/nsi/2013/04/connection/types" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<connectionId>urn:uuid:4b4a71d0-3c71-47cf-a646-beacb14a4c72</connectionId> <globalReservationId>urn:uuid:83fe4f36-5b38-41b6-bc46-a362a06a54ee</globalReservationId> <description></description> <criteria version="1"> <schedule> <startTime>2013-09-30T09:30:10Z</startTime> <endTime>2013-09-30T10:30:10Z</endTime> </schedule> <serviceAttributes> <p2p:bandwidth xmlns:p2p="http://schemas.ogf.org/nsi/2013/04/connection/p2pservice">1000</p2p:bandwidth> <p2p:path xmlns:p2p="http://schemas.ogf.org/nsi/2013/04/connection/p2pservice"> <directionality>Bidirectional</directionality> <symmetricPath>true</symmetricPath> <sourceSTP> <networkId>urn:ogf:network:netherlight.net:2012</networkId> <localId>uvalight-netherlight</localId> </sourceSTP> <destSTP> <networkId>urn:ogf:network:netherlight.net:2012</networkId> <localId>netherlight-czechlight</localId> </destSTP> </p2p:path> <surf:sNCP xmlns:surf="http://schemas.surfnet.nl/nsi/2013/04/services">Protected</surf:sNCP> </serviceAttributes> </criteria> </tns:reserve>
This will allow us to use the existing XSD for new service definitions without needing to modify the schema. New attributes can be imported for other namespaces when defined. It really is a simple change and it should provide good value.
Comments?
John
On 2013-06-19, at 9:51 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
On Tue, 18 Jun 2013, John MacAuley wrote:
Here is the reason you are seeing these attributes as optional: The modify command was folded into the reserve command, and therefore, must now share the same types.
Thanks. Makes sense.
However, with that in mind I think the seperation between ReservationRequestCriteriaType and ReservationConfirmCriteriaType makes evene less sense. They carry the same data, and there will always need to be some sanity checking outside the xml-xsd correlation anyway.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Jeroen, In this case the XSD contracted interface is for Mb/s, and therefore, specifying a unit qualifier would be redundant. It is a nice convenience function for a human, but I do not think it provides value programatically. As for being verbose, the p2p namespace could be specified once in the serviceAttribute elements, or in the main reserve header to reduce the need to have it in every attribute. I put it there for illustration purposes. John. On 2013-06-20, at 4:13 AM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hi,
As long as we're being verbose, I would suggest to add a "unit" attribute to the bandwidth to make sure that everyone understands that this is in megabits.
Jeroen.
On 20 Jun 2013, at 05:49, John MacAuley <john.macauley@surfnet.nl> wrote:
Peoples,
To follow up with the simplification I mentioned on the call today I have pulled together two example reserve requests. Here is the current structure with dedicated bandwidth and path attributes in the criteria element.
<tns:reserve xmlns:tns="http://schemas.ogf.org/nsi/2013/04/connection/types" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<connectionId>urn:uuid:4b4a71d0-3c71-47cf-a646-beacb14a4c72</connectionId> <globalReservationId>urn:uuid:83fe4f36-5b38-41b6-bc46-a362a06a54ee</globalReservationId> <description></description> <criteria version="1"> <schedule> <startTime>2013-09-30T09:30:10Z</startTime> <endTime>2013-09-30T10:30:10Z</endTime> </schedule> <bandwidth>1000</bandwidth> <serviceAttributes> <attribute type="sNCP" targetNamespace="http://schemas.surfnet.nl/nsi/2013/04/services"> <value>Protected</value> </attribute> <attribute> <surf:sNCP xmlns:surf="http://schemas.surfnet.nl/nsi/2013/04/services">Protected</surf:sNCP> </attribute> </serviceAttributes> <path> <directionality>Bidirectional</directionality> <symmetricPath>true</symmetricPath> <sourceSTP> <networkId>urn:ogf:network:netherlight.net:2012</networkId> <localId>uvalight-netherlight</localId> </sourceSTP> <destSTP> <networkId>urn:ogf:network:netherlight.net:2012</networkId> <localId>netherlight-czechlight</localId> </destSTP> </path> </criteria> </tns:reserve>
Notice the service attributes provided. This is an example of the two ways we can specify the same thing, and in this case, it is the SURFnet subnetwork protection attribute. I would like to flatten the serviceAttributes structure to a simple ANY to give us the following:
<serviceAttributes> <surf:sNCP xmlns:surf="http://schemas.surfnet.nl/nsi/2013/04/services">Protected</surf:sNCP> </serviceAttributes>
Now onto the key point I was trying to get across. Bandwidth and path are specific to a symmetric point-to-point service. I would like to make a simple change to move bandwidth and path into serviceAttributes with their own specific p2pservice namespace. This will let us have a more generic reserve message. Here is an example:
<tns:reserve xmlns:tns="http://schemas.ogf.org/nsi/2013/04/connection/types" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<connectionId>urn:uuid:4b4a71d0-3c71-47cf-a646-beacb14a4c72</connectionId> <globalReservationId>urn:uuid:83fe4f36-5b38-41b6-bc46-a362a06a54ee</globalReservationId> <description></description> <criteria version="1"> <schedule> <startTime>2013-09-30T09:30:10Z</startTime> <endTime>2013-09-30T10:30:10Z</endTime> </schedule> <serviceAttributes> <p2p:bandwidth xmlns:p2p="http://schemas.ogf.org/nsi/2013/04/connection/p2pservice">1000</p2p:bandwidth> <p2p:path xmlns:p2p="http://schemas.ogf.org/nsi/2013/04/connection/p2pservice"> <directionality>Bidirectional</directionality> <symmetricPath>true</symmetricPath> <sourceSTP> <networkId>urn:ogf:network:netherlight.net:2012</networkId> <localId>uvalight-netherlight</localId> </sourceSTP> <destSTP> <networkId>urn:ogf:network:netherlight.net:2012</networkId> <localId>netherlight-czechlight</localId> </destSTP> </p2p:path> <surf:sNCP xmlns:surf="http://schemas.surfnet.nl/nsi/2013/04/services">Protected</surf:sNCP> </serviceAttributes> </criteria> </tns:reserve>
This will allow us to use the existing XSD for new service definitions without needing to modify the schema. New attributes can be imported for other namespaces when defined. It really is a simple change and it should provide good value.
Comments?
John
On 2013-06-19, at 9:51 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
On Tue, 18 Jun 2013, John MacAuley wrote:
Here is the reason you are seeing these attributes as optional: The modify command was folded into the reserve command, and therefore, must now share the same types.
Thanks. Makes sense.
However, with that in mind I think the seperation between ReservationRequestCriteriaType and ReservationConfirmCriteriaType makes evene less sense. They carry the same data, and there will always need to be some sanity checking outside the xml-xsd correlation anyway.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
On Wed, 19 Jun 2013, John MacAuley wrote:
Notice the service attributes provided. This is an example of the two ways we can specify the same thing, and in this case, it is the SURFnet subnetwork protection attribute. I would like to flatten the serviceAttributes structure to a simple ANY to give us the following:
<serviceAttributes> <surf:sNCP xmlns:surf="http://schemas.surfnet.nl/nsi/2013/04/services">Protected</surf:sNCP> </serviceAttributes>
I like this construction.
Now onto the key point I was trying to get across. Bandwidth and path are specific to a symmetric point-to-point service. I would like to make a simple change to move bandwidth and path into serviceAttributes with their own specific p2pservice namespace. This will let us have a more generic reserve message. Here is an example: [snip] This will allow us to use the existing XSD for new service definitions without needing to modify the schema. New attributes can be imported for other namespaces when defined. It really is a simple change and it should provide good value.
This certainly makes the CS protocol way more flexible in specifying circuits, and to some extent I like it. The problem is timing as we are close to sending the document to the editors, and complete lack of discussion in the group about the base of this. Previously we have discussed the option of having aggregation points, where to point-to-point connections could be connected (the underlying NRM can choose whatever to make this happen), but this takes a completely other approach (though non fundementally incompatible). There is also the whole multi-domain aspect to consider. How we do multicast and protected paths across those in a proper way. Anything single-domain with NSI is point-less IMHO. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
I strongly suggest that we limit any addition changes now in V2 to only those that correct something that is broken or that clearly does not work as is. We could continue to tweek stuff forever and many of these changes should be considered more thoroughly by the group. There *will* be additional considereations we are going to have to address in v3 (things like protection are a good example of issues that were not discussed in our v2 requirements and need a broader discussion anyway.) Besides, stuffing something in now will not necessarilly prevent it from being reviewed and possibly changed again in V3 anyway. Lets try to stop these elective "improvements" and get v2 out the door. J We will have a chance to On 6/20/13 9:45 AM, Henrik Thostrup Jensen wrote:
On Wed, 19 Jun 2013, John MacAuley wrote:
Notice the service attributes provided. This is an example of the two ways we can specify the same thing, and in this case, it is the SURFnet subnetwork protection attribute. I would like to flatten the serviceAttributes structure to a simple ANY to give us the following:
<serviceAttributes>
<surf:sNCP xmlns:surf="http://schemas.surfnet.nl/nsi/2013/04/services">Protected</surf:sNCP>
</serviceAttributes>
I like this construction.
Now onto the key point I was trying to get across. Bandwidth and path are specific to a symmetric point-to-point service. I would like to make a simple change to move bandwidth and path into serviceAttributes with their own specific p2pservice namespace. This will let us have a more generic reserve message. Here is an example: [snip] This will allow us to use the existing XSD for new service definitions without needing to modify the schema. New attributes can be imported for other namespaces when defined. It really is a simple change and it should provide good value.
This certainly makes the CS protocol way more flexible in specifying circuits, and to some extent I like it. The problem is timing as we are close to sending the document to the editors, and complete lack of discussion in the group about the base of this.
Previously we have discussed the option of having aggregation points, where to point-to-point connections could be connected (the underlying NRM can choose whatever to make this happen), but this takes a completely other approach (though non fundementally incompatible).
There is also the whole multi-domain aspect to consider. How we do multicast and protected paths across those in a proper way. Anything single-domain with NSI is point-less IMHO.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
The SURFnet subnetwork protection mechanism is definitely domain specific based on the service offered to their customers. That is why specifying a service attribute within the SURFnet namespace is the way to go as it isolates the feature to their network. We have had this capability in the protocol since version 1.0, but I just want to clean up the XSD definition to simplify and formalize. I am not saying we remove the bandwidth and path objects, I am just saying we move them into the serviceAttributes where they really should belong since they are service specific. Decoupling these two attributes will give us much needed flexibility, and hopefully, reduce the need for another protocol change for something as simple as adding an asymmetric service definition. I have no issue waiting and submitting this as a public comment to correct the current protocol deficiency. John. On 2013-06-20, at 9:45 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
On Wed, 19 Jun 2013, John MacAuley wrote:
Notice the service attributes provided. This is an example of the two ways we can specify the same thing, and in this case, it is the SURFnet subnetwork protection attribute. I would like to flatten the serviceAttributes structure to a simple ANY to give us the following: <serviceAttributes>
<surf:sNCP xmlns:surf="http://schemas.surfnet.nl/nsi/2013/04/services">Protected</surf:sNCP> </serviceAttributes>
I like this construction.
Now onto the key point I was trying to get across. Bandwidth and path are specific to a symmetric point-to-point service. I would like to make a simple change to move bandwidth and path into serviceAttributes with their own specific p2pservice namespace. This will let us have a more generic reserve message. Here is an example: [snip] This will allow us to use the existing XSD for new service definitions without needing to modify the schema. New attributes can be imported for other namespaces when defined. It really is a simple change and it should provide good value.
This certainly makes the CS protocol way more flexible in specifying circuits, and to some extent I like it. The problem is timing as we are close to sending the document to the editors, and complete lack of discussion in the group about the base of this.
Previously we have discussed the option of having aggregation points, where to point-to-point connections could be connected (the underlying NRM can choose whatever to make this happen), but this takes a completely other approach (though non fundementally incompatible).
There is also the whole multi-domain aspect to consider. How we do multicast and protected paths across those in a proper way. Anything single-domain with NSI is point-less IMHO.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
One more: In ReserveConfirmedType, there is this element entry: <xsd:element name="criteria" type="tns:ReservationConfirmCriteriaType" minOccurs="0" maxOccurs="unbounded" /> Under what circumstances do we allow 0 or multiple of these? I can understand multiple criteria in a query, but I'd think that ReserveConfirmed should just return the resources for the revision specified in the reserve request. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi Henrik- I want to point out the the "bandwdith" is actually a service specific parameter, where as the other two aspects (schedule and path) are generic and apply to the general semantic of a "connection" regardless of service definition. Different services may have different ways to define the connection capacity...bandwidth, timeslots, spectral width, etc. Even two similar services may define their service capacity differently - say an implicit constant bit rate, or a committed information rate with burst capabilities, etc. I suppose we could consider the "size of the pipe" as a generic characteristic - it has an applicable elegance to it, but we would then need to reconcile these different ways of defining the size that might vary by service specifics... So the group should just keep this in mind - we can define an expedient solution for v2 as you suggest (I think a 80% solution that moves v2 along is most important at the moment ), but we should revisit this issue in v3. Jerry On 6/18/13 8:06 AM, Henrik Thostrup Jensen wrote:
On Tue, 18 Jun 2013, Atsuko Takefusa wrote:
I think "path" in ReservationRequestCriteriaType is a mandatory parameter.
I agree. Further:
For ReservationRequestCriteriaType
I think schedule, bandwidth and path should be mandatory.
For ReservationConfirmCriteriaType
serviceAttributes should be optional.
In fact, except for the version attribute (which is optional in one, and mandatory in another), ReservationRequestCriteriaType and ReservationConfirmCriteriaType appear to be the same.
We could consider moving version out of these use a single type. Afterall, both describe a connection. Possibly use complexContent instead, but that actually leaves more types.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
participants (5)
-
Atsuko Takefusa -
Henrik Thostrup Jensen -
Jeroen van der Ham -
Jerry Sobieski -
John MacAuley