December 2015 - Nsi-wg - lists.ogf.org

Modify behaviors
by John MacAuley 14 Mar '16

14 Mar '16

Peoples, Hans and I have been working through behaviours of the Modify operation as the NSI CS document is a little vague on some of the more detailed aspects of the operation. Our most recent discussion focused on the modification of startTime. For example, let us say reservation X has a startTime of "now + 1 hour", but I would like to modify the startTime to start "now". In an initial reservation request we specify at startTime of now by omitting the <startTime> element, however, for a modify operation we cannot distinguish from a startTime not specified for modification and the startTime intentionally missing to indicate "now". In the current schema definition we cannot use an empty <startTime> element as it is an illegal xsd:dateTime. So that only leaves us with the option of specifying a <startTime> reasonably close to now, but well all now how troublesome this is with our current implementations. There is a solution to this issue. If we modify the existing schema to allow for the "nillable" option on startTime we can now specify an empty <startTime xsi:nil="true" /> element to handle this "start time of now" case. This would require a non-backwards compatible change for modify, but I am not sure how may NSA implementations of modify exist. The second issue is what happens if in the modify request a parameter with the same value is provided? Do we fail the modify or continue with the same value? For example, if a modify is received with the same startTime but a different endTime do we reject to modify since it contains the same startTime, or do we accept the modify and only change the endTime? I would assume we accept the modify operation an proceed with modification of endTime. What happens if only one parameter, say capacity, is specified and it contains the same value as the current reservation version? Thanks, John

2 4

minutes from today's NSI call ...
by Guy Roberts 23 Dec '15

23 Dec '15

… are available here: https://redmine.ogf.org/dmsf_files/13510 Guy Roberts PhD Senior Transport Network Architect Tel: +44 (0)1223 371316 Mob: +44 (0)7881 336417 Skype: guy1965 GÉANT Networks • Services • People Learn more at www.geant.org<http://www.geant.org/> GEANT Limited, trading as GÉANT. Registered in England & Wales. Registration Number 2806796. Registered Office – City House, 126-130 Hills Road, Cambridge CB2 1PQ

1 0

Wednesday's NSI conf call
by Guy Roberts 21 Dec '15

21 Dec '15

The following is dial-in information for Wednesday's NSI call, time: 7:00 PDT 10:00 ET, 15:00 GMT, 16:00 CET, 24:00 JST 1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285 Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code 8937606, followed by "#" Agenda: - Check open APs: https://redmine.ogf.org/dmsf_files/13509 - Review outstanding NSI documents Guy Roberts PhD Senior Transport Network Architect Tel: +44 (0)1223 371316 Mob: +44 (0)7881 336417 Skype: guy1965 GÉANT Networks • Services • People Learn more at www.geant.org<http://www.geant.org/> GEANT Limited, trading as GÉANT. Registered in England & Wales. Registration Number 2806796. Registered Office – City House, 126-130 Hills Road, Cambridge CB2 1PQ

1 0

will not be able to attend this Wednesday's call
by Hans Trompert 21 Dec '15

21 Dec '15

Sorry. Cheers, HansT.

1 0

RSM in NSI CS v2.1
by Guy Roberts 10 Dec '15

10 Dec '15

Hello All, The NSI CS v2.1 document has been updated with the latest RSM as per the action point on me in yesterday’s NSI conf call: https://redmine.ogf.org/dmsf_files/13486 Guy Guy Roberts PhD Senior Transport Network Architect Tel: +44 (0)1223 371316 Mob: +44 (0)7881 336417 Skype: guy1965 GÉANT Networks • Services • People Learn more at www.geant.org<http://www.geant.org/> GEANT Limited, trading as GÉANT. Registered in England & Wales. Registration Number 2806796. Registered Office – City House, 126-130 Hills Road, Cambridge CB2 1PQ

1 0

minutes from today's NSI call
by Guy Roberts 09 Dec '15

09 Dec '15

… are available here: https://redmine.ogf.org/dmsf_files/13509 Guy Roberts PhD Senior Transport Network Architect Tel: +44 (0)1223 371316 Mob: +44 (0)7881 336417 Skype: guy1965 GÉANT Networks • Services • People Learn more at www.geant.org<http://www.geant.org/> GEANT Limited, trading as GÉANT. Registered in England & Wales. Registration Number 2806796. Registered Office – City House, 126-130 Hills Road, Cambridge CB2 1PQ

1 0

Wednesday's NSI conf call
by Guy Roberts 08 Dec '15

08 Dec '15

The following is dial-in information for Wednesday's NSI call, time: 7:00 PDT 10:00 ET, 15:00 GMT, 16:00 CET, 24:00 JST 1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285 Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code 8937606, followed by "#" Agenda: - Review NSI CS delta document: https://redmine.ogf.org/dmsf_files/13507 - Review progress of outstanding NSI documents Guy Roberts PhD Senior Transport Network Architect Tel: +44 (0)1223 371316 Mob: +44 (0)7881 336417 Skype: guy1965 GÉANT Networks • Services • People Learn more at www.geant.org<http://www.geant.org/> GEANT Limited, trading as GÉANT. Registered in England & Wales. Registration Number 2806796. Registered Office – City House, 126-130 Hills Road, Cambridge CB2 1PQ

1 0

Re: [Nsi-wg] CS delta document
by Guy Roberts 03 Dec '15

03 Dec '15

Hello Hans, I have updated the CS v2.0 to v2.1 delta document here: https://redmine.ogf.org/dmsf_files/13507 V3 of the delta document includes two further changes and a clarification– see track changes. Guy Guy Roberts PhD Senior Transport Network Architect Tel: +44 (0)1223 371316 Mob: +44 (0)7881 336417 Skype: guy1965 GÉANT Networks • Services • People Learn more at www.geant.org<http://www.geant.org/> GEANT Limited, trading as GÉANT. Registered in England & Wales. Registration Number 2806796. Registered Office – City House, 126-130 Hills Road, Cambridge CB2 1PQ

1 0

Updates to NSI CSv2.0 RSM
by Chin Guok 02 Dec '15

02 Dec '15

Hi all, In last week's telecon, we discussed modifying the NSI CSv2.0 Reservation State Machine (RSM) to provide the AG with the ability to reflect when one of its children has a reserve_timeout event and transitions from the ReserveHeld to the ReserveTimeout state. After several iterations we've come up with some changes to the RSM (CSv2.1) that provides this capability and is backwards compatible with the existing RSM (CSv2.0). Please review the changes in the attached slide deck and voice any comments to the mailing list. Thanks! - Chin Chin Guok NOC: (510) 486-7600 Network Engineer (800) 333-7638 ESnet Network Engineering Group (AS293) Lawrence Berkeley National Laboratory

1 0

Bug in recursive query
by John MacAuley 01 Dec '15

01 Dec '15

All, Yesterday while doing some bug testing I ran across an issue in the specification of recursive query results in relation to versioned reservations. I have had a couple of reads through the CS 2.0 document and believe we need to better specify how modifications are handled, especially relating to results returned in query* operations. I believe this is due to different sections being written with different understandings of the behaviour at the time. I know we changed a few times how the version numbers would be handled. This is visible in the text. Section 4.3.1 describes what I believe people have implemented. If there is no committed version of a reservation then only the base reservation information is returned (connectionId, globalReservationId, description, requesterNSA, and connectionStates) with no <criteria> element. This means no versioning and no service specific information is visible in a query. Once a version is committed then the <criteria> information for that version is returned. If the reservation is being modified then the <criteria> for the last committed version is returned. 4.3.1 Reservation State Machine (page 11) Modification of a reservation is supported in NSI CS v2.0. The reserve request message is used for both the initial reservation and subsequent modifications. A version number is specified in the reservation request message. The number is an integer and should be monotonically increasing with each subsequent modification. The version number is updated after a commit results in a transition back to the ReserveStart state. A query will return the currently committed reservation version number, however, if the initial version of the reservation has not yet been committed, the query will return base reservation information (connectionId, globalReservationId, description, requesterNSA, and connectionStates) with no versioned reservation criteria. Details of how the version number should be managed can be found in Section 6.1.6. Question: While a reservation is being modified does the <reservationState> reflect the current state of the modification even though the <criteria> represents the last committed version? I believe it does. This needs to be added to section 4.3.1 text for clarification. Sections 6.1.6 and 8.5.1.30 are currently in conflict. I believe I wrote 8.5.1.30 when we were using "0" as a special version number to show the currently uncommitted first reservation criteria. This decision was later changed to what is described in 6.1.6. We need to update the text in 8.5.1.30 to better reflect reality. 6.1.6 Reservation Versioning Information (page 26) To support the modification of reservations, the notion of versioning has been introduced to identify the instance of a reservation over its lifetime. Versioning MUST be used as follows: Version numbers are integer values ≥ 0 (zero) Version numbers are assigned by the RA when a reservation request (i.e. NSI_rsv.rq) is made to a PA If a version number is not specified in an NSI_rsv.rq, it is assumed to be 0 (zero) regardless of whether the request is theinitial or a subsequentrequest. An NSI_rsv.rq with a version number ≤ the (highest) current committed reservation version number will result in a failed request and an appropriate error 8.5.1.30 ReservationRequestCriteriaType (page 89) Type definition for a reservation and modification request criteria. Only those values requiring change are specified in the modify request. The version value specified in a reservation or modify request MUST be a positive integer larger than the previous version number. A version value of zero is a special number indicating an allocated but not yet reserved reservation and cannot be specified by the RA. Lastly we have an issue with the current definition of the ChildRecursiveType that holds the reservation results of a child NSA in the recursive query. Instead of having the <criteria> element as 0..unbounded like it is for the base reservation, I missed updating the schema definition for modify and still have the child <criteria> element as 1..unbounded. Therefore, the recessive query breaks when attempting during the reservation phase for the first version. Below is a pictorial of the issue. I will take an action to update the schema. John

1 0