Subject: RE: [NSIS] common signalling application functions

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 24 May 2004 16:58:45 +0100

[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: [email-masked] 
> [mailto:[email-masked]]
> Sent: Friday, April 30, 2004 15:24
> To: David Oran
> Cc: [email-masked]; [email-masked]; Hancock,
> Robert; [email-masked]; 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 [email-masked]
> > 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 
> >> [email-masked] https://www1.ietf.org/mailman/listinfo/nsis
> > 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________ nsis mailing list 
> > [email-masked] https://www1.ietf.org/mailman/listinfo/nsis
> > 
> 
> 
> 
> 
> 
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis