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