Re: [v6tc] Re: Tunneling and Transition Drafts

Jerome Durand <jdurand@renater.fr> Fri, 08 April 2005 08:05 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 EAA16391; Fri, 8 Apr 2005 04:05:46 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJodc-0006bb-Uq; Fri, 08 Apr 2005 04:14:49 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJoLj-0003ip-S7; Fri, 08 Apr 2005 03:56:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJoLf-0003ih-Oi for v6tc@megatron.ietf.org; Fri, 08 Apr 2005 03:56:16 -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 DAA15671 for <v6tc@ietf.org>; Fri, 8 Apr 2005 03:56:13 -0400 (EDT)
Received: from mail1.renater.fr ([193.49.159.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJoUN-0006Ji-KM for v6tc@ietf.org; Fri, 08 Apr 2005 04:05:16 -0400
Received: from [193.49.159.162] (helo=[193.49.159.162]) by mail1.renater.fr with esmtp (Exim 4.50) id 1DJoLA-0006Cw-9P; Fri, 08 Apr 2005 09:55:46 +0200
Message-ID: <4256390A.5000808@renater.fr>
Date: Fri, 08 Apr 2005 09:55:54 +0200
From: Jerome Durand <jdurand@renater.fr>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Thomas Narten <narten@us.ibm.com>
Subject: Re: [v6tc] Re: Tunneling and Transition Drafts
References: <200504071854.j37IseAs006430@rotala.raleigh.ibm.com>
In-Reply-To: <200504071854.j37IseAs006430@rotala.raleigh.ibm.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam detection software, running on the system "mail1.renater.fr", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see postmaster@renater.fr for details. Content preview: > 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. [...] Content analysis details: (0.0 points, 5.0 required) pts rule name description ---- ---------------------- --------------------------------------------------
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: 7bit
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>
Sender: v6tc-bounces@ietf.org
Errors-To: v6tc-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: 7bit

> 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 point here is that as an ISP, I'd prefer to work with a standard, 
manageable and available solution. Is one already available? If yes that 
is worth documenting how to use/deploy it (in v6ops WG). If not, then we 
have to adopt a new standard (in v6tc as v6ops is not made for it).

Jerome





> 
> One (big!) example. There was lots of talk at the BOF and in the
> presentation about the need for low latency, i.e., it was a
> "requirement". And I hear "wireless" mentioned and "3G" at
> approximately the same time. But, my understanding is that 3GPP has
> already decided to go with ISATAP. So, they aren't a customer for this
> work. But if that is the case, where is the real requirement for low
> latency coming from?
> 
> Is my understanding correct in this regard?
> 
> Thomas
> 
> _______________________________________________
> v6tc mailing list
> v6tc@ietf.org
> https://www1.ietf.org/mailman/listinfo/v6tc


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