Re: [v6tc] Re: Tunneling and Transition Drafts

Jeroen Massar <jeroen@unfix.org> Fri, 08 April 2005 08:42 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18637; Fri, 8 Apr 2005 04:42:49 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJpDU-0007gC-0U; Fri, 08 Apr 2005 04:51:52 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJp4N-0002YC-Rw; Fri, 08 Apr 2005 04:42:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJp41-0002TY-JA for v6tc@megatron.ietf.org; Fri, 08 Apr 2005 04:42:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18550 for <v6tc@ietf.org>; Fri, 8 Apr 2005 04:42:03 -0400 (EDT)
Received: from 213-136-24-43.adsl.bit.nl ([213.136.24.43] helo=purgatory.unfix.org ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJpCk-0007cW-9r for v6tc@ietf.org; Fri, 08 Apr 2005 04:51:06 -0400
Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 893858880; Fri, 8 Apr 2005 10:41:56 +0200 (CEST)
Subject: Re: [v6tc] Re: Tunneling and Transition Drafts
From: Jeroen Massar <jeroen@unfix.org>
To: Jerome Durand <jdurand@renater.fr>
In-Reply-To: <4256390A.5000808@renater.fr>
References: <200504071854.j37IseAs006430@rotala.raleigh.ibm.com> <4256390A.5000808@renater.fr>
Organization: Unfix
Date: Fri, 08 Apr 2005 10:41:54 +0200
Message-Id: <1112949714.26936.25.camel@firenze.zurich.ibm.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1.1
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: "v6tc@ietf.org" <v6tc@ietf.org>
X-BeenThere: v6tc@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: v6tc.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/v6tc>, <mailto:v6tc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/v6tc>
List-Post: <mailto:v6tc@ietf.org>
List-Help: <mailto:v6tc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/v6tc>, <mailto:v6tc-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1349637590=="
Sender: v6tc-bounces@ietf.org
Errors-To: v6tc-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a

On Fri, 2005-04-08 at 09:55 +0200, Jerome Durand wrote:
> > I do detect that there are folk that want to form a WG and that there
> > are some that believe there is a problem here to be solved (that needs
> > solving), but so far (AFAIK) the problem hasn't been articulated
> > clearly and (still) strikes me as a bit of a moving target.
> 
> The problem that was explained is how an ISP gives easily connectivity 
> to its customers, waiting for access networks/equipments/technologies to 
> be upgraded. I think this is a good problem that needs to be solved 
> (talking here as an ISP)
> 
> Now I guess what is important to get is that we need something quickly, 
> or new equipments will come before we have adopted anything. One could 
> argue we can wait 5 more years and don't bother much. This is not what 
> we did and we (as other ISPs) started to buy some commercial tools 
> (tunnel brokers) fulfilling all our requirements (low latency is not a 
> requirement for us). Tunnel discovery is not a problem for an ISP that 
> doesn't care much  giving a TEP IP address to its customers (or 
> preconfiguring the tunnel broker client). Then I can't understand that 
> this could be a stopper for not making the group.

The only thing you need is a well known anycast IP address where your
clients can find the TSP server at. Currently you configure this using a
hostname which can found in DNS and giving your clients this preconfiged
tool. What you want is that the default configfile that comes with TSP,
the one defaultly installed by the various OS's already supporting it,
have the anycast IPv4 address in it. You just announce that IP to your
customers, maybe leaking it to other ISP's who are allowed to use your
TSP and done.

The same thing is what I would want to have for my TIC thing, currently
we simply 'hardcode' tic.sixxs.net, as TIC is only used by SixXS anyway,
this is not an issue, when others would like to use it though they would
need to provide an entry for the tic server in the config file, though,
like TSP they can also request that certain accounts are redirected to
another server which will handle the client.

Just in case people wonder why I did not go with TSP: it did not fulfill
the various requirements we had, like being able to use it to turn
tunnels on/off, move tunnels and a lot of other things, in a command
oriented way, thus without having to use/depend on xml. TSP for the rest
works fine and for instance AICCU can easily be converted to make use of
it, though we will need to devise a couple of templates for things like
AYIYA and heartbeat in those cases then though.

Btw, with "low latency", people still mean 'the minimum amount of
packets required to do the configuration phase' or do they mean the
actual latency towards the endpoint of the tunnel, that is the latency
caused when the packet goes over the network? In the latter case, as
these tunnel endpoints are mostly inside the ISP's network, that is
maybe 2ms more than the path would be in native IPv6. At least that is
the case with my home dsl line.

As for "Setup latency", setups maybe happen only once an hour, does a
delay for maybe 10ms really annoy you then when every packet needs 30ms
to reach the other site afterwards anyway?

Finally a call up for 'what is the problem':

Could the people who 'require' an alternate solution than TSP, specify
what the problems are with it and possibly list what their proposed
solution* would be?

Greets,
 Jeroen

* = simply saying 'can't use that' without having an argument on how to
possibly solve it is imho quite useless ;)

_______________________________________________
v6tc mailing list
v6tc@ietf.org
https://www1.ietf.org/mailman/listinfo/v6tc