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

Sam Hartman <hartmans-ietf@mit.edu> Mon, 21 September 2009 18:10 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 10C933A68F6 for <lisp@core3.amsl.com>; Mon, 21 Sep 2009 11:10:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.333
X-Spam-Level:
X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=-0.068, 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 oHWTaauoOnMO for <lisp@core3.amsl.com>; Mon, 21 Sep 2009 11:10:19 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 329343A6825 for <lisp@ietf.org>; Mon, 21 Sep 2009 11:10:19 -0700 (PDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B4A4D413B; Mon, 21 Sep 2009 14:11:18 -0400 (EDT)
To: "Darrel Lewis (darlewis)" <darlewis@cisco.com>
References: <20090919171820.746426BE628@mercury.lcs.mit.edu> <4AB5AA3C.5090805@firstpr.com.au> <C0ACCB7B60E6F14B9AC46D742C1009A15D0AAD@xmb-sjc-213.amer.cisco.com>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Mon, 21 Sep 2009 14:11:18 -0400
In-Reply-To: <C0ACCB7B60E6F14B9AC46D742C1009A15D0AAD@xmb-sjc-213.amer.cisco.com> (Darrel Lewis's message of "Mon\, 21 Sep 2009 10\:25\:08 -0700")
Message-ID: <tsl8wg8cgmx.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: Noel Chiappa <jnc@mercury.lcs.mit.edu>, Robin Whittle <rw@firstpr.com.au>, lisp@ietf.org
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 18:10:20 -0000

>>>>> "Darrel" == Darrel Lewis (darlewis) <darlewis@cisco.com> writes:

    >> 
    >> I am not saying there isn't a viable business model for PETRs.
    >> I am just saying that I don't know what the business model is
    >> for PETRs and that I think that at least one seemingly viable
    >> model should be proposed before the whole PETR concept is
    >> accepted.
    >> 
    >> 
    >> 

Here is a simple one.  A provider wants to advertise that it allows for
    Darrel> IPv6 connectivity, but it does not have equipment in the
    Darrel> access network that supports v6 natively.  So it offers a
    Darrel> v6 service that includes a CPE device that runs LISP, and
    Darrel> some PETRs for those CPE's to use when accessing non-LISP
    Darrel> sites.  IPv6 packets sent from the hosts at the site are
    Darrel> encapsulated in v4 and sent over the access network that
    Darrel> does not support v6.

Speaking as an individual, I'd like to find deployment models f
Speaking as an individual, this deployment model has two problems:

1) The IETF already has other solutinos in that space with a lot more
successful deployment than LISP (6to4, Teredo, probably even 6rd).

2) This deployment model does not actually get to the deployment we
need.

As I understand it, for interworking to be useful, we need to get to a
point where everyone using LISP either

A) Is on a link that can loosen URPF

or
B)  has a PETR they can use.

So, you need to show that there are sufficient insentives to make
PETRs available to all lisp sites on access networks that are going to
enforce URPF.  Combining with v6 deployment doesn't really seem to
help this much.

I can see insentives for whomever is selling you your EID to make a
PETR available to you, but unless you are going to end up tied to a
single ISP, I don't see why they will be in a position to make a PETR
available close to you.