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

[Jerry Sobieski]

Hey John - some good thouhts below.

See comments inline.
J

On 7/5/12 12:59 PM, John MacAuley wrote:
> First off we will need to change the hiding the shadow connection 
> behind the same connectionId as the existing reservation, and instead 
> us a new connectionId.  This is where the existing proposal falls over 
> since there is no way to directly address or manipulate the new 
> modified reservation while the existing reservation is still in service.
We could define a "version" number...XYZ(v0) -> modify takes it to 
XYZ(v1) -> next modify takes it to XYZ(v2)...etc.     If you want the 
ability to roll back, you *must* uniquely identify each version of the 
connection somehow and associate the resources with each.    What if yet 
another Modify() request arrives before the first modify is fully 
completed?    I agree we need to differentiate "before" and "after" 
connections somehow...  But this is true of the separate Modify command 
as well....
>
> Secondly, we will need to modify the existing reserve command to take 
> a new type that will identify if the request is a new reservation, a 
> modify of an existing reservation, or perhaps a new reservation that 
> has some dependency on an existing reservation (say for diverse routing).
True.  see below.
> In addition, if we are doing anything other than a new reservation we 
> will need to provide the connectionId of the existing reservation to 
> provide context for this new reservation.
EXACTLY.   This is my point!   You want to find the common aspects of 
all of these related requests...  The common thread is _/the set 
resources that are available to the path finder/_:  For the the normal 
Reserve() any resources that are marked "available" can be considered.  
For the modify Reserve() its got to use a) resources assigned to the 
"before" connection and/or b) "available" resources.   For the diverse 
Reserve(), the path finder can consider only resources that are 
"available" *and* "greater than X distance" from the referenced 
connection(s).

These are all path finding constraints, i.e. policy imposed by the RA(!) 
- not really a different protocol process.   If we can see this - and 
see how it could help us down the road to do things like diverse path or 
parallel/reverse path, etc. it helps us avoid a potentially very costly 
SM change that will not scale to the other types of requests...
> New reservation - reserve(type="new", connectionId="ABCD");
> Modify reservation - reserve(type="modify", connectionId="WXYZ", 
> refConnectionId="ABCD");
Or the <new connectionID> == <exisitng conneiton ID> ?
> New reservation diverse to existing reservation 
> - reserve(type="diverse", connectionId="HIJK", refConnectionId="ABCD");
sure.  Again - your "refConnectionID" is actually just a means of 
identifying certain resource constraints to be applied to the PF process.
>
> Now we can still independently control both the original reservation 
> and the new reservation.
YES!  No new SM required.

We do want to consider how we ascribe characterisitcs like "these two 
connections cannot be active at the same time" ...  or we could allow 
both to be active - and its the Users responsibiity to only use one at a 
time.  But this could possibly be part of the higher layer composite 
functionality...
>  For example, if I get a partial reserveFailed I can use 
> terminate(connectionId="WXYZ") to clean up while not impacting 
> original reservation "ABCD".  I can also query both reservations 
> independently and see that there is another reservation related 
> through a pending modify operation.
>
> This also fixes the provision issue in the current shadow proposal. 
>  In the current proposal I would need to Release and then Provision so 
> that we do an 
> Activated->Releasing->Reserved->Provisioning->Provisioned->Activated 
> sequence of state transitions resulting in a traffic hit.
hmm?   My shadow proposal just suggested the user Releases the working 
Connection, and then Provisions the modified Connection (or 
re-Provisions the same connections ID but the Provision function uses 
the new version.)   It could be simpler:  once the shadow is reserved 
confirmed and waiting for a manual start, a Provision Request on the 
shadow recognizes that it is linked to the working connection and can 
either a) try to directly Provision(new) the new version (thus possibly 
avoiding the hit), or b) Release(old)-Provision(new) creating a brief hit.

IMO - a modify is not a network outage. I.e. it does not need to be 
"hitless.   It is a user RA initiated request.  The PA can impose a 
potential hit without feeling guilty.

And even for just a schedule extension, unless there is a requirement 
that schedule extensions be treated in a special manner (special hard 
coded cases...not generally a great idea) then even a simple extension 
may incure a path modification.

> With a separate connectionId I can kick the provision off on the new 
> reservation connectionId="WXYZ" while the existing 
> reservation connectionId="ABCD" is still active.
>
> provision(connectionId="WXYZ") 
> -> Reserved->Provisioning->Provisioned->Activated
>
> As the new reservation connectionId="WXYZ" transitions to Activated 
> the existing reservation connectionId="ABCD" is transitioned from 
> Activated to Terminated.  We can give a terminated reason of "Modify 
> successful" to track the change.  The termination of the original 
> reservation will be entirely handled by the uPA involved in the 
> modification of the reservation, however, since we are doing the final 
> coordination on the children NSA (i.e. moving from connectionId="ABCD" 
> to connectionId="WXYZ"), these NSA will need to generate a forced_end, 
> or perhaps a new modify_end event up the tree to notify the parents of 
> the modify and termination of connectionId="ABCD".
>
> There is an interesting side-effect of this model.  The new 
> reservation does not need to follow the same path as the original 
> reservation.  We may want to force an "in-place" option to stop 
> additional new domains getting involved in the reservation, but even 
> if they did it should work correctly.
Exactly.   If the resource constraints say "PF *must* first use existing 
resources of old version for new version" then the path will not change 
- entirely (one could see an VCAT/LCAS split path occuring.)   However, 
if we say "PF *should* use pre-existing resources in new version" it 
allows the pathfinding to allocate a different path if that will allow 
the modify to complete.

I think a more powerful resource constraint specification in the Reserve 
message would also be highly beneficial to remote pathfinders that 
simply want a segment to do something specific - like exit one domain 
into a specific next hop domain but otherwise do not care which path is 
used...
> For example, lets say the original path traversed domain B, but when 
> the aggregator NSA did path computation it determined the new 
> reservation should traverse domain C instead of domain B, but all 
> other domains remained the same.  As the 
> provision(connectionId="WXYZ") propagates down the tree the uPA 
> involved in the new reservation activate their resources, and 
> terminate any resources associated with connectionId="ABCD" 
> (obviously, domain B does not get the provision since it has no new 
> resources, and domain C has no old resources).  All other domains 
> generate with original reservation segments generate 
> a forced_end/modify_end event up the tree, which will eventually 
> result in a terminate(connectionId="ABCD") being sent to domain B for 
> its lone segment.
This is why I think for a modify functionality we cannot escape there 
being a transitionary period as we reconfigure from the old to the new.  
Even just a schedule extension will cause a period of time when some of 
the segments will have the new end time, and some will have the old end 
time.   This transition may not always require a hit in the data plane 
(such a schedule extension might or might not take a hit- depending on 
the path resources used.)

>
> Very interesting solution to the problem, however, there will be some 
> impact on the existing state machine.  I guess we need to decide if 
> overloading the existing reserve command is worth not introducing the 
> new Modify command set and it's associated state machine.
Hmm... No.  If we do this right, the existing state machine 
(transitions) remains the same, but some of the states themselves do 
more intelligent things.

I really suggest if we think about the modify as creating a new 
connection with certain resource constraints that we can safely avoid a 
substantial increase in protocol complexity.   We need to also remember 
that few users will actually take advantage of the modify capability, 
and we need to make sure we do not make the SM so complex that users 
cannot understand it...which we are close to doing.
>
> John.
>
BEst regards
Jerry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120709/1bad24a7/attachment-0001.html>