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.
BEst regards
Jerry