[Nsi-wg] CS 2.1 cannot send only the parameters to be modifed

Wed Nov 30 07:28:00 EST 2016

Hi John,

On 25/11/2016 16:40, John MacAuley wrote:
>
> On 2016-11-25, at 5:25 AM, Hans Trompert <Hans.Trompert at SURFnet.nl
> <mailto:Hans.Trompert at SURFnet.nl>> wrote:
>
>> Yes, this does make it a little bit more clear, but questions remain.
>>
>> I understand that if you want to modify one of the elements you have
>> to send it in a Modify request as a standalone element. So if I want
>> to modify two elements I have to send them in two separate elements
>> like below?
>> <p2p:capacity>500</p2p:capacity>
>> <p2p:parameter type="protection">UNPROTECTED</p2p:parameter>
>
> Yes, this is correct.
>
>> I'm I correct that this implies that it is not allowed to send a
>> complete p2p element with all the elements in it and only change the
>> ones you want modified?
>
> My thought on this was no.  You cannot add the full p2p element as
> this would imply (or set an expectation) that members of that element
> are modifiable when they are in fact not.
>
>>
>> Furthermore, the first paragraph says that only the elements to be
>> modified are included in the request, but the second paragraphs says
>> that if a modification request contains modifiable elements that are
>> the same as the currently reserved values, the modification request
>> should proceed through the reserve state machine lifecycle as if
>> changed values were successfully applied, effectively only increment
>> the criteria version. So is it allowed to send elements that did not
>> change or not?
>
> I believe this condition came out of a discussion with you back in
> December 2015 :-)
>
> The idea was that if capacity was already 500 and you requested a
> modification to 500 then we would accept this as a valid request and
> run through the connection state machine returning success.  This
> assumes the philosophy that a service modification to an existing
> value is not invalid (i.e. setting a boolean variable to true that is
> already true is not a programming error).  Nothing is stopping the NSA
> from actually doing a modification internally to change the capacity
> from 500 to 500.
>
> Does this make sense?

Yes and no ;-) You do confirm that the behavior should be as described
in document. Although I doubt if you can call changing something to the
same to be a change.

    change

        verb
        make or become different.

        noun
        an act or process through which something becomes different.

That is why i think that the phrase "only the elements to be modified
are included" is in conflict with the phrase "If a modification request
contains modifiable elements that are the same as the currently reserved
values". But nevertheless, this is how we will implement it, and for the
record, we will prevent the uPA doing unneeded calls to the underlying NRM.

Cheers,
    HansT.

> On 23/11/2016 16:44, John MacAuley wrote:
>>> I will read the section again since it must not be clear.  Here is
>>> what a modify message looks like for capacity:
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <soapenv:Envelopexmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
>>>        
>>> xmlns:headers="http://schemas.ogf.org/nsi/2013/12/framework/headers"
>>>        
>>> xmlns:p2p="http://schemas.ogf.org/nsi/2013/12/services/point2point"
>>>         xmlns:nsi="http://schemas.ogf.org/nsi/2013/12/connection/types"
>>>         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>         xsi:schemaLocation="
>>>         http://schemas.xmlsoap.org/soap/envelope/ file:../envelope.xsd
>>>         http://schemas.ogf.org/nsi/2013/12/connection/types
>>> file:../ogf_nsi_connection_types_v2_0.xsd
>>>         http://schemas.ogf.org/nsi/2013/12/framework/types
>>> file:../ogf_nsi_framework_types_v2_0.xsd">
>>>     <soapenv:Header>
>>>         <headers:nsiHeader>
>>>            
>>> <protocolVersion>application/vnd.ogf.nsi.cs.v2.provider+soap</protocolVersion>
>>>            
>>> <correlationId>urn:uuid:390be79e-5b49-4688-9280-e49b139595e2</correlationId>
>>>            
>>> <requesterNSA>urn:ogf:network:es.net:2013:nsa:nsi-requester</requesterNSA>
>>>            
>>> <providerNSA>urn:ogf:network:es.net:2013:nsa:nsi-aggr-west</providerNSA>
>>>            
>>> <replyTo>https://nsi-aggr-west.es.net/requester/reply</replyTo>
>>>         </headers:nsiHeader>
>>>     </soapenv:Header>
>>>     <soapenv:Body>
>>>         <nsi:reserve>
>>>            
>>> <connectionId>urn:uuid:4b4a71d0-3c71-47cf-a646-beacb14a4c72</connectionId>
>>>             <criteriaversion="2">
>>>                 <p2p:capacity>500</p2p:capacity>
>>>             </criteria>
>>>         </nsi:reserve>
>>>     </soapenv:Body>
>>> </soapenv:Envelope>
>>>
>>> This is include only the capacity element that is defined in the p2p
>>> schema as a standalone element for the purposed of modification.
>>>  This is not including the full <p2ps> element and using
>>> optionality.  It is including the <capacity> element.  If you look
>>> at the p2p service schema this is parameter defined as modifiable in
>>> the p2p service (startTime and endTime are in the CS schema itself).
>>>
>>> You may ask why it was done this way… It allowed us to have the
>>> original reservation request have mandatory elements for the
>>> service, but the modify to only contain those elements being changed.
>>>
>>> Does this make it any clearer?
>>>
>>> John
>>>
>>> On 2016-11-23, at 8:49 AM, Hans Trompert <Hans.Trompert at SURFnet.nl
>>> <mailto:Hans.Trompert at SURFnet.nl>> wrote:
>>>
>>>> Dear NSI WG members,
>>>>
>>>> The CS 2.1 document states in section 15.7 that only the elements
>>>> to be modified are included in a modify request. However, in the
>>>> schema the p2p parameters directionality,  capacity, sourceSTP and
>>>> destSTP are not optional. As a result the example modify requests
>>>> in figure 154 and 155 will not pass schema validation.
>>>>
>>>> If the four parameters are made optional in the schema it will also
>>>> be possible to leave them out in the initial reserve request, which
>>>> will cause problems because all four of them belong to the minimum
>>>> set of parameters in this stage. Or the schema is left as is making
>>>> it mandatory to always send the minimum set of parameters in every
>>>> modify request, in this case section 15.7 should be updated to
>>>> reflect this.
>>>>
>>>> Please advise how to proceed.
>>>>
>>>> Cheers,
>>>>     HansT.
>>>> _______________________________________________
>>>> nsi-wg mailing list
>>>> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
>>>> https://www.ogf.org/mailman/listinfo/nsi-wg
>>>
>>
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
>> https://www.ogf.org/mailman/listinfo/nsi-wg
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20161130/aafb4625/attachment-0001.html>