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

"Darrel Lewis (darlewis)" <darlewis@cisco.com> Mon, 21 September 2009 18:38 UTC

Return-Path: <darlewis@cisco.com>
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 A3B163A6959 for <lisp@core3.amsl.com>; Mon, 21 Sep 2009 11:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.56
X-Spam-Level:
X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 YgHRPEX7B4WB for <lisp@core3.amsl.com>; Mon, 21 Sep 2009 11:38:27 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C88663A6825 for <lisp@ietf.org>; Mon, 21 Sep 2009 11:38:27 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAF9lt0qrR7PE/2dsb2JhbAC7BIhQAY5TBYIzgWiBXYkj
X-IronPort-AV: E=Sophos;i="4.44,425,1249257600"; d="scan'208";a="95668372"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 21 Sep 2009 18:39:29 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n8LIdTkN027293; Mon, 21 Sep 2009 11:39:29 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n8LIdTpx004507; Mon, 21 Sep 2009 18:39:29 GMT
Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 11:39:29 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 21 Sep 2009 11:39:28 -0700
Message-ID: <C0ACCB7B60E6F14B9AC46D742C1009A15D0B0F@xmb-sjc-213.amer.cisco.com>
In-Reply-To: <tsl8wg8cgmx.fsf@mit.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [lisp] LISP Interworking: Proxy Egress Tunnel Routers
Thread-Index: Aco65v+YMCKszBRkQ/6brywlipcxWgAAcKMQ
References: <20090919171820.746426BE628@mercury.lcs.mit.edu><4AB5AA3C.5090805@firstpr.com.au><C0ACCB7B60E6F14B9AC46D742C1009A15D0AAD@xmb-sjc-213.amer.cisco.com> <tsl8wg8cgmx.fsf@mit.edu>
From: "Darrel Lewis (darlewis)" <darlewis@cisco.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
X-OriginalArrivalTime: 21 Sep 2009 18:39:29.0448 (UTC) FILETIME=[DA67E280:01CA3AEA]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2276; t=1253558369; x=1254422369; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20<darlewis@cisc o.com> |Subject:=20RE=3A=20[lisp]=20LISP=20Interworking=3A=20=20Pr oxy=20Egress=20Tunnel=20Routers |Sender:=20; bh=IBIc+T3h13fWcd6vJi3KhtwA46Ah9u25Ggkw5DBFk38=; b=T2yM0XbeCeuG/SwQEZNGMQqUq/VVpTJGM/y456OKCbjnvTQP8AO4zk53Y1 oGTXwLBxEzBfX/OditWX4g2VoGLTqDvPHRuzYYYYL+mEIJCxYRzHLKP6JVIm cMnjGF4twJ;
Authentication-Results: sj-dkim-4; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
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:38:28 -0000

 > Speaking as an individual, this deployment model has two problems:
> 

To be clear, I also am speaking as an individual.

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

It is one of many possible ones, and since it is one we have existence
proof for (there are many over the top providers offering v6 via GRE
today), I used it as an example.  I don't think that we're required to
exhaustively discuss the deployment and business models for an
experimental protocol.

But if you like I can provide another example of a virtual over the top
provider offering LISP, VPN, and other services.

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

To be specific, the provider has to work around strict uRPF.  The draft
provides a few examples of how to do this, including using a less strict
version, or (preferably) adding a static route to the EID space on the
PE router.

> or
> B)  has a PETR they can use.
> 

Or 

C) they use LISP-NAT

> So, you need to show that there are sufficient incentives 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.

This is not correct, NAT is always an option.

For v6, we have a difference of opinion here it seems.  I believe that
using this to hop over my provider's v4 only access network is
interesting.  I don't see why the existence of alternatives should
preclude LISP experimenting with this problem - certainly there are
other alternatives to the routing problem (like shim6) that have not
precluded experimentation with LISP.

> 
> I can see incentives 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.

If we can see the incentives, that should be enough correct? 


-Darrel