On Sep 29, 2010, at 7:31 AM, Gigi Karmous-Edwards wrote:
Jerry,
For your question : " While the guard times may be network specific, we
do need to at least consider what we would like an NSA to do if for
instance a provisioning guard time pushes a reservation forward into a
previous reservation: Do we 1) reject the request since we can't
prepend our guard time and still make the Requested Start Time? OR
2) Do we retard the Estimated Start Time to allow for the guard
time? OR 3) do we reduce the guard time to fit the available lead
time?"
In my opinion, I think the answer here has to be # 1) each NSA must
reject the request if their process to establish the connection
requested can not meet the Start time. In my opinion an NSA should NOT
be allowed to change the requested start time (this will cause all
types of problems for other NSAs), so # 2) is not an option. The guard
time for each NSA will most likely be vastly different and very
dependent on the tools used by that network domain to configure the
network elements for the requested path, so an individual guard time of
an NSA is also nonnegotiable, so option # 3) is not an option.
I agree #1 seems the most deterministic.
I agree with Radek, ONLY Start times and End times should be used in
the protocol and that guard times are only private functions of each
individual NSA.
I agree with this. The guard times are not additive across
each NSA. The guard time from the perspective of the user will
effectively be the maximum of each NSAa guard time in the chain. But,
the user doesn't care as long as provisioning is accomplished by the
users requested start time. That time would be in the protocol and
would remain unchanged through each step of the chain. And, it
shouldn't matter how long it takes to tear down the circuit either as
long as the circuit is available until their requested end time.
As to how to manage this time synchronization... I think it is
totally reasonable to depend upon existing protocols. There are other
protocols that already depend upon time synchronization, and many of
them use NTP. We are not talking about needing very tight
synchronization anyway. 1 second or even 10 seconds is plenty close
enough. It is more about bounding that error.
jeff
Kind regards,
Gigi
On 9/29/10 8:45 AM, Jerry Sobieski wrote:
Hi
Inder- I am not sure I agree with all of this...
Inder Monga wrote:
Radek
I agree with your statements;
User is not interested in partial results, as he/she is
not even aware/interested in which NSAs/domains are involved. User
doesn’t care (if everything works fine ;) ).
The protocol should be designed with the user in mind.
The user does not care about guard time values, differences in setup
times for MPLS vs optical lambdas, and concern itself with choices an
NSA/NRM will make in path-finding.
The protocol designers can keep the user in mind, but the protocol
is between the RA and the PA and and has a specific purpose: to
reserve and instantiate a connection across the globe. We need to keep
in mind that the RA is not always the end user - it is by definition
another NSA and could be an NSA in the tree/chain somewhere. If we
want to differentiate between the user and the network, then we can
create a simplified User to Network API, and a different Network to
Network API...but I don't think thats what we want to do (:-) We need
to IMO *not* think about the user, but to think about the Requesting
Agent - regardless of who it represents.
Perhaps once the RA-PA protocol is tightly defined in all its nuances,
we can develop/recommend an end user API that simplifies the the
application's required interactions ?? This would allow an
application to embed an RA in a runtime library/module and the
application itself would only have to deal with the basic connection
requirements.... just a thought.
In my opinion,
a. the user should specify "Expected Start Time,
Expected End Time". The NSAs/domains along the path determine resource
availability and booking in their schedules based on their own
configured guard time (guard times are not specified by NSI protocol.
NSI connection service architecture should discuss them as a suggested
concept).
While the guard times may be network specific, we do need to at least
consider what we would like an NSA to do if for instance a provisioning
guard time pushes a reservation forward into a previous reservation:
Do we 1) reject the request since we can't prepend our guard time and
still make the Requested Start Time? OR 2) Do we retard the
Estimated Start Time to allow for the guard time? OR 3) do we reduce
the guard time to fit the available lead time?
I think we now agree that the Start Time is just an estimate, due
primarily to the guard time itself being just an estimate. So none of
these times are etched in stone...So which option do we recommend or
require? The protocol is sensitive to these various times - they
cause timers to go off, messages to be sent, error handling to kick
in... If they are adjusted during scheduling or provisioning, we MUST
understand what impact they will have to the protocol and how that will
be carried through the service tree.
b. Within reasonable limits, the connection should be up
as close to the start time as possible. The user can set his own
policy/configuration on how long to wait after the start time to accept
a connection. Since the resources are guaranteed, this is a connection
of setup/provisioning only. Hence, there is no protocol state
transition when start time is passed other than the messages that
indicate the circuit is established end to end or teardown message
initiated by the client.
Ah, but the rub here is that the "user" is an RA...but not all RAs are
the end user. We are defining the actions of an RA, regardless of
whether it is a user NSA or an network NSA. So we must insure that if
the RA gets tired of waiting for provisioning to complete, that
whatever actions it is allowed to take will be consistent and
predictable through out the service tree for all the RA/PA
interactions. So the "user" actions are not irrelevant to the
protocol.
c. We should not design a protocol that depends on time
synchronization to work. In my opinion, the start time, expected time
to provision aka guard time is best handled/shared as a SLA/Service
definition issue.
I agree: We cannot expect perfectly/exactly synchronized clocks
anywhere in the network. And therefore we cannot depend upon clock
synchronization for any part of the protocol to work. Which implies
that the protocol must work when the clocks are NOT synchronized. How
do we insure this? --> rigorous protocol analysis.
While the values of certain timers may be left to the Service
Definition/SLA, as I state before, we must make sure that the protocol
can function predictably and consistently in the face of all possible
timing permutations that are possible among NSAs. This rapidly gets
very complex if we allow too many variables for the SD/SLA to define.
Sometimes, its ok to identify constants that the protocol must use so
that we can validate the protocol and simplify implementation and
deployment. Indeed, often times when clocks are only slightly skewed
they introduce race conditions that become more likely to occur
requiring more careful consideration.
d. Similar semantics apply to the end-time as well.
Pretty much. Across the board, things like clock events, estimates,
and service specific choices will create situations where we need to
insure the protocol and state machines will function properly across
the full range of possible permuted values. This is in general why
protocol designers say "make it only as complex as it needs to be, and
no more" - options breed complexity.
br
Jerry
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg