Subject: Re: [NSIS] NTLP draft

From: karagiannis <[email-masked]>
Date: Tue, 11 Nov 2003 16:55:32 +0100 (MET)

Hi Robert and Henning

Thank you very much for the hard work!

I have some questions related to the draft:

1) Is it possible to separate the datagram mode (unreliable mode) and
connection mode (reliable mode)
specifications in two separate protocol specifications (two RFCs)?

2) Is it possible to use (in some scenarios) the datagram mode
end to end (without supporting the connection mode)? Please note that
this mode selection procedure
might be different than the one that you have described in the draft.
Of course, if a NSIS node along the path will not support
this mode then an error message might be reported to the signaling sender.

3) Why have you chosen in the datagram mode for UDP encapsulation
and not for "raw IP" encapsulation?

4) It will be interesting if the Peer-Peer Tunelled Encapsulation
(Section 5.3.3) could be applied upstream and the "End-to-End Tunnelled
Encapsulation" could be applied downstream. Is that possible?

Best Regards,
Georgios

On 10/23/2003, "Hancock, Robert" <[email-masked]> wrote:

>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

Dr. ir. Georgios Karagiannis
Group: Design and Analysis of Communication Systems (DACS)
University of Twente
The Netherlands

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