People, As agreed I have added the serviceType string to identify the corresponding Service Description that will identify the elements carried in the serviceAttributes. The updated document is attached. I will open issues to track the updates and submit the changes to the code.google repository. John
Henrik - Just so other people on the list see your comments who may not be following code.google issues. Everyone - To clear up some confusion I may have introduced. Issue #97 was added to track the addition of serviceType independent of the removal of the service attributes. I though it better to treat the two updates separately. i will be submitting an update to close #97 in a few minutes. In comment #2 below, Henrik asks if we could discard the serviceAttributes element all together and include the service specific element from external namespaces directly in the parent element. Yes we can definitely do this, and there will be no loss of information. The only difference is that we will no longer have the service related elements wrapped in the serviceAttributes clild element. In this case the XSD would be simplified to the following: <xsd:complexType name="ReservationRequestCriteriaType"> <xsd:sequence> <xsd:element name="schedule" type="tns:ScheduleType" minOccurs="0" /> <xsd:element name="serviceType" type="xsd:string" minOccurs="0" /> <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> <xsd:attribute name="version" type="xsd:int" use="optional" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:complexType> The XML example would also appear as follows: <criteria version="1"> <schedule> <startTime>2013-09-30T09:30:10Z</startTime> <endTime>2013-09-30T10:30:10Z</endTime> </schedule> <serviceType>ETS.Bidirectional</serviceType> <p2p:p2pService> <bandwidth>1000</bandwidth> <directionality>Bidirectional</directionality> <symmetricPath>true</symmetricPath> <sourceSTP> <networkId>urn:ogf:network:netherlight.net:2012</networkId> <localId>uvalight-netherlight</localId> <labels> <attribute type="vlan"> <value>1901</value> </attribute> </labels> </sourceSTP> <destSTP> <networkId>urn:ogf:network:netherlight.net:2012</networkId> <localId>netherlight-czechlight</localId> <labels> <attribute type="vlan"> <value>1901</value> </attribute> </labels> </destSTP> </p2p:p2pService> <surf:sNCP>Protected</surf:sNCP> </criteria> This change would remove the need for an additional type, and flatten the request a little further. Does anyone have any additional comments? John Project Member Reported by jmacauley, Jul 4 (2 days ago) As part of service definition decoupling from the NSI CS core protocol we need to add a ServiceType string value to reservation criteria to indicate the type of service being requested. This string value will correspond to the service definition template for the service being offered. Based on this ServiceType string value, and NSA will be able to determine the serviceAttributes required to meet the service request, and look up the service definition template. The current ReservationRequestCriteriaType definition is: <xsd:complexType name="ReservationRequestCriteriaType"> <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> This will be modified to: <xsd:complexType name="ReservationRequestCriteriaType"> <xsd:sequence> <xsd:element name="schedule" type="tns:ScheduleType" minOccurs="0" /> <xsd:element name="serviceType" type="xsd:string" /> <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> All other types containing criteria will also be modified to contain the serviceType element. Yesterday (34 hours ago) Delete commentProject Member #1 thostrup Isn't this suggestion different than the one presented in NSI_Service_Decoupling.pdf? There the criteria was essentially a schedule along with a bunch of serviceAttributes Yesterday (34 hours ago) Delete commentProject Member #2 thostrup Hi, so the current suggestion: <criteria version="1"> <schedule> <startTime>2013-‐09-‐30T09:30:10Z</startTime> <endTime>2013-‐09-‐30T10:30:10Z</endTime> </schedule> <serviceAttributes> <p2p:p2pService> .. Could we consider dumping the serviceAttributes alltogether, and going for something like this: <criteria version="1"> <schedule> <startTime>2013-‐09-‐30T09:30:10Z</startTime> <endTime>2013-‐09-‐30T10:30:10Z</endTime> </schedule> <p2p:p2pService> ... I.e., having a single ANY element. The QName of the element would define the service request type. Today (moments ago) Delete commentProject Member #3 jmacauley In response to comment #1 - I added the serviceType issue separately from the removal of service parameters into serviceAttributes. In response to comment #2 - Yes we could definitely do this, but I thought encapsulating the elements in the serviceAttributes sub element would provide a cleaner separation. I am okay with this change. On 2013-07-06, at 1:25 PM, John MacAuley <john.macauley@surfnet.nl> wrote:
People,
As agreed I have added the serviceType string to identify the corresponding Service Description that will identify the elements carried in the serviceAttributes. The updated document is attached. I will open issues to track the updates and submit the changes to the code.google repository.
John
<NSI_Service_Decoupling-v2.pdf> _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
People, I created a version of the Service Decoupling document with Henrik's suggestions. Please find it attached to this e-mail. I have also attached the changed XSD files for this recommendation. Please have look and provide comments. John On 2013-07-06, at 2:11 PM, John MacAuley <john.macauley@surfnet.nl> wrote:
Henrik - Just so other people on the list see your comments who may not be following code.google issues.
Everyone - To clear up some confusion I may have introduced. Issue #97 was added to track the addition of serviceType independent of the removal of the service attributes. I though it better to treat the two updates separately. i will be submitting an update to close #97 in a few minutes.
In comment #2 below, Henrik asks if we could discard the serviceAttributes element all together and include the service specific element from external namespaces directly in the parent element. Yes we can definitely do this, and there will be no loss of information. The only difference is that we will no longer have the service related elements wrapped in the serviceAttributes clild element. In this case the XSD would be simplified to the following:
<xsd:complexType name="ReservationRequestCriteriaType"> <xsd:sequence> <xsd:element name="schedule" type="tns:ScheduleType" minOccurs="0" /> <xsd:element name="serviceType" type="xsd:string" minOccurs="0" /> <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> <xsd:attribute name="version" type="xsd:int" use="optional" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:complexType>
The XML example would also appear as follows:
<criteria version="1"> <schedule> <startTime>2013-09-30T09:30:10Z</startTime> <endTime>2013-09-30T10:30:10Z</endTime> </schedule> <serviceType>ETS.Bidirectional</serviceType> <p2p:p2pService> <bandwidth>1000</bandwidth> <directionality>Bidirectional</directionality> <symmetricPath>true</symmetricPath> <sourceSTP> <networkId>urn:ogf:network:netherlight.net:2012</networkId> <localId>uvalight-netherlight</localId> <labels> <attribute type="vlan"> <value>1901</value> </attribute> </labels> </sourceSTP> <destSTP> <networkId>urn:ogf:network:netherlight.net:2012</networkId> <localId>netherlight-czechlight</localId> <labels> <attribute type="vlan"> <value>1901</value> </attribute> </labels> </destSTP> </p2p:p2pService> <surf:sNCP>Protected</surf:sNCP> </criteria>
This change would remove the need for an additional type, and flatten the request a little further. Does anyone have any additional comments?
John
Project Member Reported by jmacauley, Jul 4 (2 days ago) As part of service definition decoupling from the NSI CS core protocol we need to add a ServiceType string value to reservation criteria to indicate the type of service being requested. This string value will correspond to the service definition template for the service being offered. Based on this ServiceType string value, and NSA will be able to determine the serviceAttributes required to meet the service request, and look up the service definition template.
The current ReservationRequestCriteriaType definition is:
<xsd:complexType name="ReservationRequestCriteriaType"> <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>
This will be modified to:
<xsd:complexType name="ReservationRequestCriteriaType"> <xsd:sequence> <xsd:element name="schedule" type="tns:ScheduleType" minOccurs="0" /> <xsd:element name="serviceType" type="xsd:string" /> <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>
All other types containing criteria will also be modified to contain the serviceType element. Yesterday (34 hours ago) Delete commentProject Member #1 thostrup Isn't this suggestion different than the one presented in NSI_Service_Decoupling.pdf?
There the criteria was essentially a schedule along with a bunch of serviceAttributes Yesterday (34 hours ago) Delete commentProject Member #2 thostrup Hi, so the current suggestion:
<criteria version="1"> <schedule> <startTime>2013-‐09-‐30T09:30:10Z</startTime> <endTime>2013-‐09-‐30T10:30:10Z</endTime> </schedule> <serviceAttributes> <p2p:p2pService> ..
Could we consider dumping the serviceAttributes alltogether, and going for something like this:
<criteria version="1"> <schedule> <startTime>2013-‐09-‐30T09:30:10Z</startTime> <endTime>2013-‐09-‐30T10:30:10Z</endTime> </schedule> <p2p:p2pService> ...
I.e., having a single ANY element. The QName of the element would define the service request type. Today (moments ago) Delete commentProject Member #3 jmacauley In response to comment #1 - I added the serviceType issue separately from the removal of service parameters into serviceAttributes.
In response to comment #2 - Yes we could definitely do this, but I thought encapsulating the elements in the serviceAttributes sub element would provide a cleaner separation. I am okay with this change.
On 2013-07-06, at 1:25 PM, John MacAuley <john.macauley@surfnet.nl> wrote:
People,
As agreed I have added the serviceType string to identify the corresponding Service Description that will identify the elements carried in the serviceAttributes. The updated document is attached. I will open issues to track the updates and submit the changes to the code.google repository.
John
<NSI_Service_Decoupling-v2.pdf> _______________________________________________ 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
Hi On Sat, 6 Jul 2013, John MacAuley wrote:
In comment #2 below, Henrik asks if we could discard the serviceAttributes element all together and include the service specific element from external namespaces directly in the parent element. Yes we can definitely do this, and there will be no loss of information.
The XML example would also appear as follows:
<criteria version="1"> <schedule> <startTime>2013-09-30T09:30:10Z</startTime> <endTime>2013-09-30T10:30:10Z</endTime> </schedule> <serviceType>ETS.Bidirectional</serviceType> <p2p:p2pService>
Actually this was not quite what I had in mind. You don't really need the serviceType elements above. The <p2p:p2pService> is more than enough to identify the type of request. This way one will only have to look at the element name before deciding if one can process the request. It is simpler and less brittle, and provides an easier way to create new request types, as no one needs to haggle over values for what should be in <serviceType>. Furthermore, I think we should consider having a different request type for plain ethernet and ethernet with VLAN. E.g.,
<ptpeth:EthernetVLANService> <bandwidth>1000</bandwidth> <directionality>Bidirectional</directionality> <symmetricPath>true</symmetricPath> <sourceSTP> <networkId>urn:ogf:network:netherlight.net:2012</networkId> <localId>uvalight-netherlight</localId> <vlan>1901</vlan> </sourceSTP>
And one without the VLAN tag for plain ethernet. This has the benefit of making it much clearer what goes in on the request. The label stuff confuses the users a lot. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
participants (2)
-
Henrik Thostrup Jensen -
John MacAuley