Subject: (ngtrans) draft-vg-ngtrans-tsp-00.txt & draft-vg-ngtrans-tsp-v6v4profile-00.txt

From: Marc Blanchet <[email-masked]>
Date: Thu, 19 Jul 2001 19:49:38 -0400

hi,
	here is a proposal of a control protocol for tunnel establishment, called 
tunnel setup protocol, following the model of the tunnel broker. The 
protocol enables negociation of tunnel parameters (v4, v6 addresses, v6 
prefixes, etc...) and other stuff. The seminal idea came from the Peter 
Tattam proposal that was published as a note a while ago.
	this will be presented during ngtrans session in London.
	
	your comments will be very appreciated.

Marc.
===============================================================================
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Tunnel Setup Protocol (TSP)
	Author(s)	: M. Blanchet
	Filename	: draft-vg-ngtrans-tsp-00.txt
	Pages		:
	Date		: 18-Jul-01
	
This document proposes a control protocol to setup tunnels between a
client and a tunnel server or broker.  It provides a framework for
the negociation of tunnel parameters between the two entities.  It is
a generic TCP protocol based on simple XML messaging.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-vg-ngtrans-tsp-00.txt

===============================================================================
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: IPv6 over IPv4 profile for Tunnel Setup Protocol (TSP)
	Author(s)	: M. Blanchet
	Filename	: draft-vg-ngtrans-tsp-v6v4profile-00.txt
	Pages		: 13
	Date		: 18-Jul-01
	
This document proposes a tunnel profile to setup IPv6 over IPv4
tunnels to be used with the Tunnel Setup Protocol (TSP) [9].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-vg-ngtrans-tsp-v6v4profile-00.txt

---

From: Alain Durand <[email-masked]>
Date: Thu, 19 Jul 2001 22:48:06 -0700

At 07:49 PM 7/19/2001 -0400, Marc Blanchet wrote:
>hi,
>         here is a proposal of a control protocol for tunnel 
> establishment, called tunnel setup protocol, following the model of the 
> tunnel broker. The protocol enables negociation of tunnel parameters (v4, 
> v6 addresses, v6 prefixes, etc...) and other stuff. The seminal idea came 
> from the Peter Tattam proposal that was published as a note a while ago.

 > There are current proposals about deploying configured tunnels over IPv4 
network.
 > The Tunnel Broker method (RFC3053) [1] intends to use Web browers and 
servers
 > to allow end-users to request configured tunnel but there is no real 
negociation
 > between end-user and Tunnel Broker. If end-users use dynamic IPv4 addresses,
 > a manual operation must be done to update the Tunnel Broker. This manual 
operation
 > implies to be done over a security layer to ensure a secure 
authentication of end-users.

==> RFC3053, describe the conceptual model of Tunnel Broker and list the use
        of Web Browser as a possible solution to implement it. Nothing in 
RFC3053
        prevent the use of on ad-hoc protocol in between the client and the 
broker.

 > The Tunnel Setup Protocol (TSP) approach proposes a negociation
 > of tunnel parameters between Tunnel clients and Tunnel Servers.

==> Why limiting this protocol to the dialog from the client to the tunnel 
server?
        Why not having this dialog with the broker instead? That way, the 
broker
        could share the load among several tunnel servers.

 > 4.4 broker element
 >
 > The 'broker' element is used by a server to provide a alternate list of 
servers to a client in the case where the > server is not able to provide 
the requested tunnel.

==> See previous comment. If the dialog was with the broker instead of the 
server,
        it will simplify this.

Also, as a general comment: did you consider using the tunnel broker mime type
(draft-durand-ngtrans-tunnel-mime-type-02.txt) to exchange tunnel 
informations?

         - Alain.

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 20 Jul 2001 10:03:50 -0400

At/À 22:48 2001-07-19 -0700, Alain Durand you wrote/vous écriviez:
>> tunnel broker. The protocol enables negociation of tunnel parameters 
>> (v4, v6 addresses, v6 prefixes, etc...) and other stuff. The seminal 
>> idea came from the Peter Tattam proposal that was published as a note a 
>> while ago.
>
>
> > There are current proposals about deploying configured tunnels over 
> IPv4 network.
> > a manual operation must be done to update the Tunnel Broker. This 
> manual operation
>        prevent the use of on ad-hoc protocol in between the client and 
> the broker.

totally agree. the paragraph tried to explain the differences with the 
current implementations of tunnel brokers.

>        could share the load among several tunnel servers.

the tsp protocol supports both the broker or the server model. there is no 
limitation.

>==> See previous comment. If the dialog was with the broker instead of the 

again, same as above. We will add a specific note to clarify this in the 
next version of the draft. (we haven't put all the details of the protocol 
in the draft, so expect a new version with added functionnalities).

>(draft-durand-ngtrans-tunnel-mime-type-02.txt) to exchange tunnel 

mime doesn't implement a control protocol. we feel that it is better to 
have a control protocol where the two parties exchange information in an 
interactive way: TSP supports SASL, so you could use any authentication 
mechanism, negociated between the two parties. Not easy to do with a 
mimetype in an http transaction.  Not detailed in the draft now is also an 
option to keep a keepalive in the control protocol so that it will detect 
the sustainability of layer2 (i.e. IPv4).

Marc.