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@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@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of Jerry Sobieski Sent: Thursday, February 28, 2013 12:14 AM To: John MacAuley Cc: nsi-wg@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

...

Peoples,

I understand the usefulness of having a release command from a networking

...

Would it be possible for people to provide their customer use cases for

On 2/27/13 12:38 PM, John MacAuley wrote: 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. 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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg

---

nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg

Hi Jerry,

I only pick the two most important things to react on:

On 02/28/2013 01:51 PM, Jerry Sobieski wrote:

...

During the released period, the resource can indeed be used for something else - how the "system" keeps track of this is an implementation issue. You are assuming a lot of functionality from a NRM/NMS that most of the current systems do not have an probably will not have in the (near) future. Because of the very diverse traffic profiles in NRENs the biggest problem in NREN networks is the traffic engineering, and the NSI Release is not helping here. Not really...NSI does not *assume* anything about the NRMs. I am only

Hi Hans- Thanks for the comments...I have some response in line... On 3/1/13 6:46 AM, Hans Trompert wrote: pointing out what an NRM *could* be able to do if the developers of that NRM were creative and might want to do so... I..e the Release gives the NRM this option - it does require that the NRM do anything during a Release. I find the observation a bit odd on two levels. A) NSI is not intended to simply reflect what NRMs can or cannot do. Indeed, NSI has tried very carefully to *not* define or assume anything about the NRMs beyond their general responsibility/authority to manage things internally within a domain. NSI is intended to be an _/interdomain/_ framework/protocols that everyone will agree to implement regardless of the capabilities of any particular internal NRM. NSI defines the framework and the protocol semantics - what is to be accomplished by each primitive. It is the responsibility of the NSI implementors to implement the protocol as specified and adapt/interface those NSI primitive semantics to their NRM. Thus the external behaviour and appearance of all NSI agents and domains is consistent across all NSI agents. How the implementors adapt the NSI semantics to their particular NRM context is an implementation issue we leave to them to solve. (We don't mean to make this difficult, but there are many NRMs that all behave differently - some are probably smarter than others, but we don't make a distinction.) B) The "Release" is probably the least complex primitive in the CS protocol. A Release() *IS* optional in its usage and in the life cycle of a Connection - just as a Cancel() is optional in its usage as well. I.e. a user does *not* need to Release() their Connection prior to Cancel()ing the reservation. They can have an active circuit and immdeiately Cancel the reservation, or just do nothing and let it expire, and both the active circuit and the reserved resources all goes away fine. However, this does not mean the Release() primitive is optional in the protocol implementation. A PA /must/ implement the Release as it is a legitimate and required primitive in the protocol. (This is the issue we are discussing - whether to keep the primitive in the protocol or not.) *IF* a user RA issues a Release command, the PA is bound by the standard to recognize it, process it as specified, and change the Connection's state to "released". It is here that the standard has left great leeway to the implementors in that we did not specify what happens to the resources associated with the Connection during the released window. All we said is that the Connection is no longer In Service (i.e. not "Active") and that the Reservation is retained so that the Connection can subsequently be re-provisioned. This actually requires very little of the PA implementation - i.e. the NRM may in fact not do anything internally...just sits there with an idle Connection in place. Why is this hard or difficult? In such a case, an NSI Query would return a "Released" state...as should any children. And as stated, there is no _/requirement /_for the data plane to be functional during a Release'd window - though in many cases might in fact remain unchanged. (Continuing to carry traffic while released I think may pose a security issue,...but its a corner case we needn't worry about right now.) So, as it stands, the NRMs are not required to do much (if anything) to effect a "released" state. The NSA will need to reflect the state, and the NSA is expected to progress the Release() down the service tree to inform any children, but the NRM pretty much just has to say "Ok...I'll ignore alarms until I get the order to reactivate it." ... right? Then - if and only if you want to - you could have your NRM do something wonderful or useful with the suspended resources like shunt some best effort traffic across that links, or maybe you noticed FEC errors increasing but hadn't caused any issues yet, and so you might want to adjust power or attenuation to see if they can push them back down... NSI does not currently state what you can or cannot do while the Connection is Released... only that the data plane is _/not required/_ to be functional, and data plane resources should remain allocated so that the circuit can be brought back into Active state. (I don't think it even officially asserts that the same resources are required...just that the Connection as specified can be re-Activated ...) I think the Release concept needs re-analysis...potentially even should be expanded or redefined. Maybe it should be renamed to "Suspend()" to avert confusion about what it does. It should be able to be sent up the tree as well as down the tree - thus allowing uPAs to request that the circuit be idled in order to address a problem and thus giving the user a means of gracefully handling an unexpected and/or temporary interruption. This would also allow a problem encountered in one domain to be communicated upstream and downstream to other domains serving the connection instance. It probably should have an optional restart time or suspension duration - which would allow the RA or PA to indicate/know how much time is available or when it must be active again...a veritable auto-start for re-provisioning. All of these have both positive and negative second and third order affects on the protocol and framework - and the implementations as well - and I assert that these should be thoroughly considered before we take a decision and change anything. Thus (IMO) the change is not critical, but is also non-trivial, and so we should not make a rushed decision now as we are trying to get v2 out the door.

I'm fine with the Release being in CS 2.0 but please make it optional. And please do not make any major changes to CS 2.0 any more, this months OGF is the NSI WG last chance of making this version final IMHO. My proposal for today is exactly this: leave it as is for now.

Side comment about "optional" primitives or fields in a standard: Be clear on what we mean by "optional" in terms of /implementation/ and "optional" in terms of /usage/. A field may be defined as optional in its usage meaning that if it is present it _/must be recognized/_ and processed according to the standard, but it is not required to be present. This *requires* an implementation to "implement" the field even though it may be optional in its usage. Alternatively, a field or primitive that is described in the standard, _/but is not required to be recognized/__/*and* processed in a specific manner/_, is essentially a non-standard extension and should not be included at all as part of the "standard". In the standard, there are no optional primitives or fields that need not be implemented. Even if the processing of a specific field is "may be ignored" it must nevertheless be recognized and processed in that manner. i.e. it *must* be implemented. This is how we treat Modify() in version 2 - as optional in its usage - it *must* recognized, and can be processed as: one of two actions: a) it may be ignored and a status reflecting such is returned, or b) it can be acted upon to modify the parameters associated with a connection. Thus Modify must be implemented, even if there is an escape clause that says you can just essentially ignore it for now (on the presumption that it is a complex task that may take a while to be actually be functionally enabled.)

...

We put it on the list of v3 issues and have the discussion then. We already have 4 customers who have implemented CS 1.0sc into their software. With the introduction of CS 2.0 we will support them to make the move from 1.0 to 2.0 as we do not want to keep 1.0 around for to long. We have to spend a fair amount of resources on this. Please do not expect that we are willing to do this again any time soon to move from 2.0 to 3.0. As far as I am concerned, anything that is not in 2.0 right now we will have to learn to life without for quite some time (assuming you want to avoid forcing people to do all kinds of complex multi version aggregation).

This is exactly why I caution the Working Group that *ANY* change to any aspect of the standards needs to be VERY CAREFULLY considered in_/all /_ its implications before including it, or excluding it. I don't think anyone is trying to be callous regarding the efforts developers invest to get things to work. They are to be commended for diving in early - and you all for lending them assistance - this certainly helps define the end result. But there *will* be changes and enhancements to NSI over the coming years. We can't do it all at once, thus we have a phased approach of version 1, then version 2, version 3,... Hopefully, and I think demonstrably, the work is incrementally improving and converging to a mature set of protocol primitives that will change less from one version to the next. I would assert that there are still features that even the users would like to see matured and evolve. Some of these changes will affect existing code, some will not. For instance, a Topology Service may be relevant to some agents while others will ignore it altogether; the Discovery Service that at least advertises the versions an agent runs is an attempt to make the reality of different versions less of an obstacle to deployment and development, monitoring and performance verification services need to integrate smoothly, and ability to build multi-point connections, and integration with SDN environments, or a Modify capability that has been tested and proven... Modify is a good example- We delayed that from v1 to v2 because it was a very complex process that had *many* implications. Nevertheless it was deemed a necessary feature for emerging service environments...and driven by users who wanted the capability. That is the case now with point-to-multipoint, and topology distribution, and monitoring, and I will bet you there are some fundamental changes coming that will be required to make the whole framework work more reliably - and simpler - as we learn more and gain experience as we deploy it. So I do not advocate moving ahead to each new version as quickly as it hits the press. Production codes and environments are by nature conservative in this sense. And the NSI WG is sensitive to the issue of version migration and backward compatibility. Indeed, we have had some heated debates on how to address this particular issue. One last soapbox comment: The NSI effort is a "Standards" effort. This is not an engineering project. The NSI objective is to find _/agreement and consensus/_ so that we all do these things in the same way - everywhere. We have a group of autonomous organizations with very broad set of interests, infrastructure, expertise, policies, and requirements. There is no king to decide how we proceed - as a group we all need to reach agreement in order to proceed because to do otherwise will not produce a standard. This becomes a political process as much as a technical process. It requires both a high level of technical expertise, an ability to advocate, explain, listen, and compromise, and a significant amount of time for the group to reach a common set of concepts and processes. I suspect if you put four smart people in a room they may be able to progress faster, but I think the result would be far less impressive and you will continue to have other folks building islands of incompatible services. The NSI framework is novel because we did/do have an /open/ forum that incorporated some novel ideas and for that reason it takes longer than most managers or technical folks think is necessary or or are comfortable with. On the other hand, we have been taking a technical approach to these capabiliteis for 20+ years and still have no common or ubiquitous provisioning framework.. So I am very much bullish on NSI even when it seems slow and plodding. So please try to be patient and keep the big picture in view. We *do* need to get v2 out the door asap, but as much as anything this so that networks/apps can lean on v2 while we begin working on v3 and all the features we still need to address. Thanks for the input, Hans. Best regards Jerry

Cheers, HansT. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg