-----Original Message-----
From: Hancock, Robert [mailto:robert.hancock at roke.co.uk]
Sent: Monday, May 24, 2004 5:59 PM
To: 'Yacine.El_Mghazli at alcatel.fr'; David Oran
Cc: nsis at ietf.org
Subject: RE: [NSIS] common signalling application functions
[Apologies for the late reply:]
Hi,
Considering the various options discussed:
1. I suspect it's nicer to have a dedicated toolbox that to
have re-use bits and pieces of insides of NSLPs (at least at an
early stage). But that requires more work and organisation and
documents, so it's really a question of energy ("good stuff"
as Dave describes it does not come free.) After repeated calls
for input on this subject during the framework development, we
didn't get very far (Bob made similar comments when the purpose
of the signalling analysis work was being discussed), so I think
it's probably best to consider addressing these problems in a
'bottom up' way at least for now.
2. I'm opposed to integrating this stuff into GIMPS. GIMPS
has enough non-trivial things to do without adding more things
which don't have a strong interaction with its transport
functions.
3. I checked Dave's list of common functions to see how these
things are currently being progressed, if at all. Here is my
perception:
*) precedence and pre-emption: the QoS model people have included
a proposal in their latest draft. That could be evaluated from the
perspective of other application users.
*) separation of reserve and commit phases: at the moment, I still
don't see _how_ this can be treated independently of the resource
description issue (not why it is necessary to do so), and why
finessing it as part of the resource description is a bad idea.
*) fate sharing: if this is a reference to wanting the state installed
for one application to be conditional on the state installed for
another application in failure cases, this was actually discussed
at length in the requirements phase and agreed to be a
non-requirement.
The reason is that it can get almost unboundedly complex to do this
in the network, and you can never do as good a job as in the end
system; so, why go for extra efficiency in the form of network support
when this is just to handle exceptional (failure) cases. but see
also the next point:
*) inter-nslp binding: there probably is an issue about setting up
signalling state for multiple signalling applications needing
inter-NSLP interactions and hence possibly several round trips.
I think we need examples of this to work on understanding what a
general solution would look like. We do know there is a problem with
NAT/other-NSLP interactions, but that is also a problem which affect
GIMPS as well, so I would like to see how that works out before
considering the case extending to a more general concern.
*) policy control for AAA, etc.: I have to admit I don't really
understand this one. If it is a matter of having unified handling
of NSIS resource requests in the context of a AAA architecture, it
is clearly a Good Thing; however, how much does it relate to common
interactions within a node rather than having an impact on the wire
NSIS protocols themselves?
*) route recording: i can see this as being a common (i.e. shareable)
object - provided the applications can agree on what information about
the route to record (node ingress address, node egress address, ports,
node FQDNs...). I think this sort of thing would best be handled
as a set of common diagnostic objects; Xiaoming has already done
some thinking here AFAIK.
*) explicit routing: *IF* this was to be supported as a function I
think it would have to be in the transport in some form. I raised
a previous email on whether this would ever be the case (i.e. in what
sense explicit routing would be part of NSIS scope) which
didn't really
get discussed much (see the archive around 20/04); in any case,
it is becoming clearer how to fit variable message routing methods
into GIMPS (NATFW requires it IIRC) and this would just be one more.
*) resource sharing: i think this has to be in the NSLP.
So, at the moment, while seeing that it is probably a good thing
for the NSIS 'architecture' to enable some commonality between
signalling applications, the best specific cases are already being
worked on.
robert h.
-----Original Message-----
From: Yacine.El_Mghazli at alcatel.fr
[mailto:Yacine.El_Mghazli at alcatel.fr]
Sent: Friday, April 30, 2004 15:24
To: David Oran
Cc: john.loughney at nokia.com; Ruediger.Geib at t-systems.com; Hancock,
Robert; nsis at ietf.org; Tschofenig Hannes
Subject: Re: [NSIS] common signalling application functions (was RE:
Tentative Interi m Meeting schedule)
dear all,
I participated into the design of the AAA in the QoS-NSLP
together with
hannes. I tend to agree that this should fall into the
so-called 'common
sig app functions' block.
moreover when examinating the dave's list of targetted
applications, we
could even narrow the scope of such a common block to AAA
(at large...
let's say 'policy'). concerning the design alternative
(rüdiger mentions
'toolbox' vs. cross-ref between NSLPs), IMO the first one
should lead to
a cleaner design and avoid doing twice the same thing.
I have finally a couple of comments/questions:
1) did you consider integrating such a generic 'toolbox' into
GIMPS ? or
maybe the WG wants GIMPS to keep strictly relating to transport ?
I would suggest to copy the RSVP design here: a generic
POLICY_DATA TLV
in GIMPS, which contains a list of Policy Element (PE)
objects. those
PEs would be designed separately and I'm pretty sure a couple
of already
RFCed PEs could even be re-used as is.
2) does the working group think that the design of such
generic objects
will come together with some kind of framework ? authz protocols ?
requirements ?
thanks,
yacine
David Oran wrote:
--On Thursday, April 29, 2004 1:09 PM +0300
john.loughney at nokia.com
wrote:
Robert,
The 2nd approach doesn't sound very different from how Diameter
was designed, with multiple application support. Would
that be a
good analogy, or were you thinking of something different?
Rüdiger's mail arrived first, so I didn't see your mail where you
suggested it was Diameter-like ...
Anyhow, I support your suggestion. Dave, would this
address your
concerns at all?
It solves the pragmatic problems of encoding and abstract
syntax, but
by itself does not ensure that the design of the common
functions is
in fact carefully done with the goal of generality and
extensibility
across NLSPs.
So, this is progress, yes.
Many of these common functions have impact similar to designing an
NLSP itself. It would be good if we could tackle them
directly with
people identified to do the work and ensure it meets the
needs of the
NLSPs we know about and that the specification is clean clear, and
all that other good stuff.
I think we still need further discussion of the related
problem of
ordering among NLSPs so that things like NAT translations and QoS
flow classifiers work together and don't need multiple RTTs to
establish state.
Dave.
John
_______________________________________________ nsis
mailing list
nsis at ietf.org https://www1.ietf.org/mailman/listinfo/nsis
_______________________________________________ nsis mailing list
nsis at ietf.org https://www1.ietf.org/mailman/listinfo/nsis
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis