Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers

Sam Hartman <hartmans-ietf@mit.edu> Mon, 21 September 2009 21:24 UTC

Return-Path: <hartmans@mit.edu>
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0356D3A6832 for <lisp@core3.amsl.com>; Mon, 21 Sep 2009 14:24:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.332
X-Spam-Level:
X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1rj3q29Z2gE for <lisp@core3.amsl.com>; Mon, 21 Sep 2009 14:24:25 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 2798528C0D9 for <lisp@ietf.org>; Mon, 21 Sep 2009 14:24:25 -0700 (PDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1A5BA413B; Mon, 21 Sep 2009 17:25:25 -0400 (EDT)
To: David Meyer <dmm@1-4-5.net>
References: <20090919171820.746426BE628@mercury.lcs.mit.edu> <4AB5AA3C.5090805@firstpr.com.au> <C0ACCB7B60E6F14B9AC46D742C1009A15D0AAD@xmb-sjc-213.amer.cisco.com> <tsl8wg8cgmx.fsf@mit.edu> <20090921204855.GA7205@1-4-5.net>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Mon, 21 Sep 2009 17:25:24 -0400
In-Reply-To: <20090921204855.GA7205@1-4-5.net> (David Meyer's message of "Mon\, 21 Sep 2009 13\:48\:55 -0700")
Message-ID: <tslskegat2z.fsf@mit.edu>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: lisp@ietf.org, Noel Chiappa <jnc@mercury.lcs.mit.edu>, Robin Whittle <rw@firstpr.com.au>
Subject: Re: [lisp] LISP Interworking: Proxy Egress Tunnel Routers
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2009 21:24:26 -0000

>>>>> "David" == David Meyer <dmm@1-4-5.net> writes:

    David> 	Understand that you are speaking as an individual;
    David> however, are you stating your points above are reqired
    David> either by the IETF and/or by the WG? That is, are you
    David> Experimental RFCs should not be developed when there are
    David> other solutions in the same general space? 

We have a fairly specific charter for why we're developing LISP.
I don't think easing IPv6 transition is part of it.
As an individual, I prefer that the WG not spend its energy working on problems where that's the motivation.
I prefer that when we do work on a problem that we try and think about v6 transition.
So, if we do PETRs, we should make them friendly to transition.
However, since we're not in the transition business, we shouldn't do PETRs simply for transition.

Also, yes, I definitely believe it's the case that the IETF should not
do work that is not needed.  I'd hope I don't need to find an RFC to
back that up.  It's my opinion that we have a lot of operational
experience with Teredo and 6to4, and that suggests we're not really
looking for additional mechanisms to tunnel v6 over v4 to get around
NATs and access network issues.  There is some work within the charter
of softwires focused around providing that sort of transition as a
service.  I agree that is needed, although I think even they concluded
they didn't need new encapsulations.

    David> 	With respect to assertion 2): I understand that this
    David> is your (and perhaps others) opinion. However, there are
    David> many other folks with opinions that differ from yours, so
    David> I'm not sure what the significance of your statement is in
    David> the context of WG's milestones.

Well, these people with different opinions need to write to the list
for their opinions to be considered.  So far, the people who have
opinions as far as the WG are concerned are Darrel, Noel, Robbin and
myself.


Presumably since you're writing you have a different opinion.

My assertion #2 roughly boiled down to two parts:

A) If PETRs are going to solve the interworking problem for people who
have URPF blockage, then those people need a PETR they can use.

B) It seems fairly clear to me that if people deploy PETRs as a v6
transition service, they won't be available to the right people to
solve the interworking problem.

I'm hoping to get Darrel to focus on the deployment incentives for
PETRs as a part of the interworking problem between LISP sites and
non-LISP sites, not other deployment incentives that might also
increase the global number of PETRs.