Subject: RE: [NSIS] NTLP draft

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 4 Nov 2003 19:29:22 -0000

hi marcus, all,

> Robert, all,
> 
> In general I think it is a good starting point for discussion.

phew!
to be serious: if this -00 version can help the WG to come to
a consensus on whether to follow the approach described in section 3
or to do something different, it will IMHO have served its purpose.

about the general approach described in 3...
> > The view has been expressed that this is a good approach to
> > investigate, but that there are some consequences which have
> > to be worried over. We hope that the description now in the draft
> > is clear enough to allow the WG to make its mind up on the
> > matter. In particular, section 5.3 describes the problems
> > and some possible cures (some people may find some of the
> > cures worse than the problems).
> >
> 
> Section 5.3 was really the point were I got lost. I have seen 
> the several 
> options, but did not figure what the difference really is, 
> and why the raw 
> encapsulation is not sufficient.

the best I can do is point to the example given in appendix C.
the point is (using the terminology of that example), that the 
NSLPs at A and F really want the services of a messaging 
association between themselves, but the necessity of intermediate
nodes to do some actions on the signalling messages means that
if you use raw mode, the messaging association has to be broken
into pieces. you then have to decide whether this breaking is
a problem or not.

> 
> >
> > As a general point, this version is long (very long) on
> > explanation and discussion, and short on actual specification.
> > In fact, my impression is that GIMPS (or whatever we call it)
> > is actually a rather simple protocol, which can behave
> > in a number of very complicated ways and has a number of
> > very complicated interactions with other protocols. So,
> > in the longer term, we may need to think about how to structure
> > the specification to reflect this (somewhat unusual) situation.
> 
> The main problem I see is the flexibility which is still in 
> there. I think 
> we need to define quite a number of parameters in a static 
> way. There is a 
> lot of language saying "if you want to do that then configure 
> ....". In 
> many cases it is not clear who is deciding on the choices 
> (And I think we 
> already had some discussion on the topic).

this is something that I think has to be handled case by
case. we tried to pick out the major ones (where the impact is
on more nodes than just the one making the choice) in section 8.
this sort of flexibility has to be carefully justified.
however, IMHO there are other sorts of flexibility (where there
is implementation freedom in how to process messages at a node
which doesn't change what's required of other nodes) which is
much less dangerous.

> 
> The other thing I did not get:
> 
> 1) the GIMPS State (section 4.1). Why is the session id not 
> enough as index?

two reasons:
a) if multiple signalling applications were using the same session
id (which is currently not ruled out), and if the GIMPS is 
bypassing NSLP-unaware nodes for some signalling applications,
then the identity of the next/previous peer can depend on the
signalling application.
b) the flow id can change for a session (ip mobility) or there
can be more than one (ip multihoming).

it is probably the case that more discussion might allow us to
restrict how session ids are allowed to map to application/flow
ids (currently this is left pretty free).

> 
> 2) For route change propagation I would assume a notification 
> per-application sitting on the node detecting the change 
> might work fine. 
> Would mean that the GIMPS keeps state for applications not 
> supported on the 
> specific node (which might be the case when only using raw 
> encapsulation.)

this is a partial answer. but then there are two implications:

a) GIMPS needs to store state for applications not supported
on that node. This might well mean storing state for flows
not otherwise interesting to that node. This might be happening
anyway (you want connection mode and chose raw encapsulation) but
would also even happen in datagram mode. This could lead to 
an explosion in flow storage requirements (think of all the middlebox
application signalling state that core qos-nslp-only routers would
end up with).

b) even if the node stores state about the application it doesn't
support, what does it then do with the notification? (i.e. the
problem hasn't gone away.)

> 
> Concerning the Open Issues
> 
> 8.1) in GIMPS I don't like the word messaging in GIMPS. I 
> would vote for 
> GIST

or any other choice (the field is open...)

> 
> 8.2) + 8.3) I don't see why raw IP would not work for datagram mode.

i think basically it would work, although I forsee some problems
(mainly in some nat-traversal cases). are there actual advantages
to raw IP?

> 
> 8.4) I don't see why we need to care about letting signaling messages 
> travel on the fast path (no processing on the node). Putting too much 
> optimization into a design normally causes more problems than 
> gain, and we 
> optimize for todays technology, which might change as well.

philosophically I agree, especially if we are talking about strictly
'protocol internal' functionality. when we are talking about the 
interface between NSIS and 'the rest of the Internet' I think the
situation is slightly different. think about all those core nodes
who want to do at most lightweight processing of some very specific
qos-nslp having to do slow-path processing of some other signalling
application which is really only interesting to edges. this could
have a major effect on the network.

> 
> 8.5) I propose to use 3 types of associations (unreliable, reliable, 
> secure), finer granular differentiation only complicates 
> without too much 
> gain.
> 

this is a defensible position. i would like to see more views.

> 8.7) I am in favor of raw mode. Seams to be the simplest one 
> without to 
> much impact.

please see above.

> 
> 8.10) scope should be a function for applications needing it, I don't 
> regard it as general functionality.

this is a defensible position also. again i would like to see more views.

> 
> 8.11) Reverse routing should be optional, it allows for 
> stateless operation 
> in the core

an alternative view would be that the statelessness in the 
core could be supported by non-raw encapsulation and we lose the
complexity of having to decide whether reverse state has been stored
or not. (the problems come in error cases where reverse routing
state is available on some parts of the path but not others).

there is also some interaction here with whether we allow route
recording (6.3).

> 
> 8.12) additional discovery mechanisms are really nice in various 
> environments. Is there an impact on the protocol definition, 
> or is this 
> more an implementation issue?

this is a good question. we have slightly underemphasised the
issue (for fear of re-opening the on/off-path debate). 
some parts of the protocol are unaffected by how the
routing state is set up (all of 4.2); some parts are affected
(much of 4.3). The threat picture (threats against routing
state integrity, 7.3) definitely changes, as do some aspects of
the routing interactions (6.1). 

so, i would say it is definitely more than an implementation 
issue - or rather, we cannot promise it is only an implementation
issue without doing more analysis work. However, the basic 
protocol design is in principle open to other mechanisms for
filling in the routing state table, and some extensions may be 
useful even while we are restricted to the path-coupled case.

> Kind regrad,
> Marcus
& cheers,

r.

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