[Nsi-wg] Release command

Thu Feb 28 05:26:55 EST 2013

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