Subject: [NSIS] NTLP draft

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 23 Oct 2003 09:57:00 +0100

Dear all,

You will (I hope) be pleased to know that there is now a 
wg -00 NTLP draft. While it works through the i-d editor
queue, you can find a copy at

http://nsis.srmr.co.uk/~reh/draft-ietf-nsis-ntlp-00.txt

This can be seen as a development of the ideas in the drafts
that were presented in Vienna and the subsequent discussion
(actually, it is still called GIMPS but the name is actually
the first in the list of open issues).

The main point is that the protocol is (hopefully now very
clearly) structured as 
- something RFC2205-like, which also supports
- use of existing transport&security protocols to achieve
  the functionality that RSVP has in 2747 & 2961

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).

There is also more discussion of other aspects of operation
as requested (e.g. v4/v6 stuff and supporting material) and
some examples for clarification. There is also a bit more
on routing interactions (although I believe this needs more
analysis before we can decide exactly what we want the 
protocol to do).

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.

enjoy,

robert h.

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

---

From: Marcus Brunner <[email-masked]>
Date: Tue, 28 Oct 2003 18:27:03 +0100

Robert, all,

In general I think it is a good starting point for discussion.
> 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 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).

The other thing I did not get:

1) the GIMPS State (section 4.1). Why is the session id not enough as index?

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.)

Concerning the Open Issues

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

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

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.

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

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

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

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

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?

Kind regrad,

Marcus