[Nsi-wg] Release command

[Jerry Sobieski]

Hi Radak-

First - I am not necessarily against a change in the protocol...just not 
now. Lets finish version 2 - no more new changes.  Wrap up what we have 
and get the specification out the door.  Any new changes, especially to 
the protocol, require careful consideration.  E.g. the state machines 
need to be reviewed - again.   I suggest it be pushed to v3 for 
discussion.

Second - on the technical aspects, if anything (including the PA) 
interupts the active circuit *for any reason* without prior 
acknowledgement by the RA, that constitutes an outage...as far as the 
user is concerned.  The Release primitive allows the RA to inform the PA 
that the resources can now be taken out of service [temporarilly] 
without breaking contract.

Third - the Release allows the user to tell the network that "I am not 
using this capacity *right now*" - and implicitly allow the network to 
use that capacity for something else- like best effort traffic, or 
maintenance, etc., without the interruption causing an alarm.   This is 
IMO *very* useful.  As yet another real use case: - a user reserves and 
tests a connection before it is actually needed (say for an important 
video presentation), the user can Release the connection until the 
required time, and then re-provision it with the confidence that the 
circuit engineering will be the same and thus the performance ought to 
be the same as tested - same latency, same path, same loss 
specifications, etc.

Fourth - we do not have a means currently for the PA to request a 
Release of the RA (i.e. *up* the tree.) This would be the means by which 
a leaf node network - having no visibility to the upstream and down 
stream Connection segmentations could pass a Release request up the tree 
allowing all the agents in the tree to be properly notified/consulted.

As for alternate use of the resources during a Released window, this is 
probably where we have not offered guidance.   But the user has no 
expectation that his traffic will flow or resume until he has 
re-provisioned the Connection and received a ProvisionConfirm.  During 
the released period, the resource can indeed be used for something else 
- how the "system" keeps track of this is an implementation issue. 
There is one proviso: that those resources are locked in some fashion to 
the Connection and will be available to re-provision when requested. 
When the user issues the re-Provision, the user should NOT get a reject 
based upon resource availability...but the [re-]provision might not be 
immediate - it might take a while as maintenance operations are 
concluded, or other traffic is groomed away...but the Provision() 
primitve already is acknowledged to be highly variable in provisioning 
times.

Finally, the current Release should probably include an optional 
re-provision time. Or a duration for the Release. THis would allow the 
PA to know when the user will again need the circuit to be active and 
functioning properly. Sort of an auto-restart for re-provisioning.:-)

So the Release seems to me to be quite useful - though it might want 
some additional features like the PA->RA capability above, or a 
duration, and perhaps some guidance on what is expected of the 
Connection performance parameters across a Release.

So, IMO any changes to the protocol requires careful consideration.  I 
do not think we should rush this or take this discussion formally now.

I suggest that we make no change and leave Release as-is for version 2. 
  We put it on the list of v3 issues and have the discussion then.

Jerry



On 2/28/13 5:26 AM, Radek Krzywania wrote:
> Jerry,
> If you have maintenance, the resources are unavailable. This is either
> scheduled and system should not book resources in that time, or forced by
> situation which is a failure for NSI (cancel/reroute/reprovision). This must
> be simple. There is a lot of questions from non-NSI people on what is the
> release and what is it purpose. The only case I can imagine is when the link
> is shared by provisioned and best effort traffic, so releasing connection
> can speed up best-effort, no-guaranteed traffic for a while. Reprovisioning
> will decrease the bandwidth for best-effort traffic without much damage. How
> likely is that to happen? Is the regular IP traffic so high we need to clear
> on-demand connections whenever possible? If I booked the resources, I am
> paying for them despite of the fact I am using them currently or not.
> Release gives some flexibility and may have some use cases, but IMHO for
> sake of simplicity we should make it optional or get rid of it at all.
>
> Best regards
> Radek
>
>
> -----------------------------------------------------------
> Radek Krzywania
> e-mail: radek.krzywania at man.poznan.pl
> phone: +48 61 850 2526
>
> Network R&D
>
> Poznan Supercomputing and Networking Center
> Noskowskiego 12/14
> 61-704 Poznan
> Poland
>
>
>
> -----Original Message-----
> From: nsi-wg-bounces at ogf.org [mailto:nsi-wg-bounces at ogf.org] On Behalf Of
> Jerry Sobieski
> Sent: Thursday, February 28, 2013 12:14 AM
> To: John MacAuley
> Cc: nsi-wg at ogf.org Group
> Subject: Re: [Nsi-wg] Release command
>
> Hi John -
>
> I know a number of implementations that have not implemented the
> Modify() command - and probably won't either.   So lets remove it also.
>      If you really want to simplify the protocol and SMs, get rid of
> Modify.   :-)
>
> but seriously...  Use cases and historical context:
>
> Many connections will be in service over weeks, months or years. The idea is
> to be able to drop the circuit from its "in service" state without releasing
> the reserved resources back to the available pool and
> risk those resources being allocated to other Connections.   The
> potential for new reservations locking out or substantially changing the
> existing reservation was deemed unacceptable.   The circuit could be
> re-provisioned as long as it was still within the reservation window.
>
> The use case would be for periodic maintenance where the circuit would be
> affected but where the interruption is expected and should not constitute an
> error.  Another use case can be where the reserved resources in one domain
> for a connection need to be modified (say a link is upgraded from 10 G to
> 100 G) - but the upstream or downstream domain
> resources should not be released back to the availability pool.   When
> the circuit data plane is broken there is no way to guaranty the privacy or
> security or reliability of user data - the Release enables the user to halt
> traffic and allow the circuit to be fiddled with....  The other domains
> should not generate alarms or otherwise act as if the connection is fully
> functional - but its not an error either.  Release is not just a cosmetic
> command.
>
> I do not think there was an intention to modify the circuit as-built
> characteristics during a release - Indeed, I think the intent was to simply
> communicate to all NSAs in the tree that the data plane can be interupted
> without causing an "outage" or triggering alarms all up and
> down the path.     So while we probably did not document in sufficient
> detail what the user would experience as result of a release and
> re-provision, the sentiment was that the circuit would be "essentially"
> the same after reprovisioning.   (e.g. "The expected performance
> characteristics should be the same before and after a Release.")    I do
> recall the discussion where we stipulated that the data flow *should* be
> actively blocked during a Release since to admit user data without
> confirmation that all segments were in service would pose a security and
> reliability flaw to the performance guarantees.  However, I do not think
> anything about curtailing the flow at ingress made it into the spec.
>
> A) Why is this difficult to implement?
>
> B) To my recollection, the Release() was never considered an "optional"
> primitive in terms of implementation, just that it could be skipped in the
> life cycle protocol sequence thus allowing an active circuit to go directly
> to a Cancel state without passing through Released.  (This means only that
> the protocol can skip the Release action in cases where it is not needed -
> not that it is an optional primitive in an NSI CS
> implementation.)    So if it is not implemented I would consider it an
> incomplete implementation.
>
> C) What behaviour are you thinking the Release is or is not doing? Or doing
> incorrectly?
>
> This seems like a new proposal when we are trying to curtail any
> additional changes - particularly major changes which I think this is.
> I think we should retain the Release() primitive in its current form for
> v2.     WE can revisit the issue in v3 ?
>
> just my thoughts..
> Jerry
>
>
> On 2/27/13 12:38 PM, John MacAuley wrote:
>> Peoples,
>>
>> I understand the usefulness of having a release command from a networking
> perspective, but I know a number of implementations are not supporting it at
> the moment (and some have no intention of supporting it).  With my new "lets
> make the state machine as simple as possible attitude" I started to wonder
> what is the customer use case for this command?  Chin had one where someone
> wanted to keep their reservation, but wanted to free up bandwidth for others
> to use.  This is an interesting use case, but not the behaviour of the
> current command as documented.  Removal of this command can significantly
> simplify the protocol and state machine.
>> Would it be possible for people to provide their customer use cases for
> this command?  I am wondering if it is truly needed, or perhaps, we have the
> incorrect behaviour defined.
>> Thank you,
>> John
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/nsi-wg
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg
>