[Nsi-wg] A alternative Modify() proposal - a "shadow" approach

[Jerry Sobieski]

Hi everyone-

The connection modification capability for version 2.0 was initially 
presented as a simple enhancement to extend the scheduled end time.  Or 
perhaps to increase the bandwidth, on an existing reservation.  This was 
supposed to be a very limited functional tweek for v2.0.

But then we decide "hitless" was a requirement;  And then we added "path 
preservation" as a requirement.  It was *assumed* that we needed a 
unique Modify() primitive to do this...  probably because prior tools 
have them...      Suddenly, _/we are re-defining the entire state 
machine/_ (yet again), and making it still more complex, in order to 
make this "simple" enhancement.

This increasing complexity is actually counter to what we were trying to 
do in Oxford: to /simplify/ the state machine.  And in general, counter 
to good protocol design.  I think the existing state machine has been 
thoroughly vetted and is adequate for the protocol, and that we should 
consider functions like "Modify" as higher layer constructs that should 
be implemented using the existing atomic primitives we already have.   
Things like protection circuits, and diversity attributes, and the like 
will all pose similar challenges - and we cant keep changing the state 
machine everytime someone has a "simple" feature they can't live without...

Given the developing complexity, we should step back and re-evaluate  a) 
the urgency for Modify(),   b) the means/scope of implementing it,   and 
c) the timeline it will require to "do it properly".

I would like to also propose an alternative "shadow" approach to provide 
a modify capability in version 2.0:

In a shadow approach, we build a simple second "shadow" connection 
reservation, and then perform a Release()-Provision() sequence to cut 
over to the modified service instance when ready.  This shadow approach 
uses only existing protocol primitives and existing state machine.    
(This is similar to John's talk about "bridge and roll"... but without a 
bridge:-)

Currently, a separate circuit approach like this would require separate 
STPs as endpoints for the modified connection reservation.  However, 
given virtual STPs (e.g. VLANs), a shadow connection would not *really* 
need to terminate at the same source or destination STP to be useful - 
i.e. the A and Z endpoints of a modified connection could be different 
VLANs without imposing any detectable performance hit on end-to-end data 
flow (!) - the sending system simply begins using a new tag when the 
shadow provisioning is completed.   (This requires the end systems 
agents to know this will occur, but, strictly speaking, this is entirely 
feasible.)   The shadow path would likely even be along the same 
geographic route - i.e. the packets would transit all the same network 
infrastructure, just with different tags.  Given this situation, the 
need to "modify" an *existing* connection, particularly with ethernet 
based STPs, seems somewhat unnecessary if you can simply request another 
connection with the desired new attributes along the same path and start 
using it whenever you please...

Being pragmatic though, there are many applications that will not be 
able to change their termination point, thus the source/destination STPs 
should be simultaneously acceptable for both the shadow connection as 
well as the working connection.  Likewise, other resources (say 
bandwidth) may not be sufficient to reserve a completely separate 
upgraded Connection, and so the path finders ought to be able to 
"double-book" resources assigned to the working connection to be used by 
the shadow connection.  Since the working conenction and the shadow 
connection should never both be active, this double booking will never 
cause a conflict.  This ability for shadows to double-book resources of 
their working counterpart provides the functionality we initially 
wanted: simply upgrading the existing path.

We can easily indicate when we wish to create a shadow Reservation 
within the existing protocol:  We simply specify an existing 
ConnectionID in a Reservation Request.   If the ReservationRequest 
specifies an existing Reservation rather than a new Reservation, then a 
[new] shadow Reservation/Connection is to be created and linked to the 
original "working" reservation.   Thus, an otherwise normal Connection 
is identified as a "shadow" connection solely by the link to a working 
Connection.    When a reservation is confirmed, if it links to a working 
connection, the RA will immediately replace the working with the shadow 
and Terminate the working reservation.   In the one case where the 
working connection is Active, the shadow will remain in its Reserved 
state as if it had passed the start time and was awaiting a provision 
request.   When a Release occurs for the working connection, a check is 
made to see if a shadow is linked to it.   If so, the shadow will then 
replace the working, and the working connection is Terminated.

This process does not change the NSI-CS protocol or the state machine.  
It incur [minor] code additions to the existing primitives, but does not 
change the event driven state transitions.  Pathfinders should to also 
be enhanced to double-book shadow resources.

This "shadow" approach has this major advantage:  Since it is 
essentially just building a second reservation, it does not require 
changing the fundamental NSI-CS protocol or the state machine.   All the 
"modification" processing is implemented using existing primitives and 
state transitions.  The cost to the user is minimal: a single 
*potential* brief hit as the A and Z endpoints are switched to the 
[new/modified] connection.  And since the user initiated the modify() in 
the first place, and will need to adjust the behaviour of the 
application to take advantage of the new characteristics, it does not 
seem unreasonable to expect the user to be able to deal with a hiccup - 
if it occurs.


Finally, as a general recommendation:  Modifying the existing primitives 
and the associated state machine should be a /last/ resort.  Any new 
feature should have a very strong case for modifying the NSI-CS state 
machine, and alternatives that do not do so should be strongly 
encouraged.   We should only modify the NSI core protocols in order to 
simplify them, delivering additional features through higher level 
service constructs wherever possible.

Thoughts?
Jerry



On 7/2/12 11:06 PM, John MacAuley wrote:
> Peoples,
>
> Here is the new and improved NSI CS state machine fresh off the presses and ready for your viewing pleasure.  Please study it and prepare questions for the Wednesday call.  We would like to close on this action ASAP.
>
> Thank you,
> John.
>
>
> _______________________________________________
> 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/20120703/d5fca3be/attachment.html>