[Nsi-wg] Release command

[Jerry Sobieski]

Hi Hans-  Thanks for the comments...I have some response in line...

On 3/1/13 6:46 AM, Hans Trompert wrote:
> 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 
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 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/20130301/8ac1e381/attachment-0001.html>