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

David Meyer <dmm@1-4-5.net> Mon, 21 September 2009 21:42 UTC

Return-Path: <dmm@1-4-5.net>
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 364AC3A6953 for <lisp@core3.amsl.com>; Mon, 21 Sep 2009 14:42:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 kGOtvitAK5CV for <lisp@core3.amsl.com>; Mon, 21 Sep 2009 14:42:13 -0700 (PDT)
Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 9AEAC3A683F for <lisp@ietf.org>; Mon, 21 Sep 2009 14:42:13 -0700 (PDT)
Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-6) with ESMTP id n8LLhCXF009332; Mon, 21 Sep 2009 14:43:12 -0700
Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n8LLhCh3009331; Mon, 21 Sep 2009 14:43:12 -0700
X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f
Date: Mon, 21 Sep 2009 14:43:12 -0700
From: David Meyer <dmm@1-4-5.net>
To: Sam Hartman <hartmans-ietf@mit.edu>
Message-ID: <20090921214312.GA8975@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> <tslskegat2z.fsf@mit.edu>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7"
Content-Disposition: inline
In-Reply-To: <tslskegat2z.fsf@mit.edu>
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I just had to let it go. John Lennon"
User-Agent: Mutt/1.5.18 (2008-05-17)
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:42:18 -0000

On Mon, Sep 21, 2009 at 05:25:24PM -0400, Sam Hartman wrote:
> >>>>> "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.

	Ok, fair enough. However easing v6 transition was just
	used as an example. The topic was (as you know) on
	interworking, which is part of the charter. Please see
	http://www.ietf.org/dyn/wg/charter/lisp-charter.html.

	That stipulated, note that the title of the Interworking
	Draft is "Interworking LISP with IPv4 and IPv6". Since
	that draft is clearly within the current scope of the WG,
	are you calling for recharting the WG? If so, please
	provide a formal request to both the WG and ADs.

> As an individual, I prefer that the WG not spend its energy
> working on problems where that's the motivation. 

	That's fine. 

> I prefer that when we do work on a problem that we try and
> think about v6 transition. 

	Please clarify. I couldn't parse that in the context of
	the rest of your note.


> So, if we do PETRs, we should make them friendly to transition.

	Of course, I think everyone wants that.

> However, since we're not in the transition business, we
> shouldn't do PETRs simply for transition. 

	Again, you've just asserted something that is neither
	supported by the charter or any consensus call that I
	know of.

> 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.

	I'm sorry, here "what's needed" is an arbitrary call on
	your part. Can you support your definition of "what's
	needed" with anything other than that assertion? 

> 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.

	Again, these are arbitrary assertions. Please provide a
	proceedural artifact to support this. If you can not to
	this, then the above statement is not relevant to the
	operation of the WG.

>     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.

	Different than what?

> 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.

	You've just restated your opinion, which to be blunt
	doesn't help. You might also explictly state what you
	would like the WG to accomplish (and provide process
	artififacts other than just restating your opinion).
	
	Dave