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

"Darrel Lewis (darlewis)" <darlewis@cisco.com> Mon, 11 January 2010 20:32 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 C01DD3A6951 for <lisp@core3.amsl.com>; Mon, 11 Jan 2010 12:32:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 xR-b9lvv9lFB for <lisp@core3.amsl.com>; Mon, 11 Jan 2010 12:32:21 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id ED85A3A6926 for <lisp@ietf.org>; Mon, 11 Jan 2010 12:32:20 -0800 (PST)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEABsZS0urR7H+/2dsb2JhbADDHJQEhC8E
X-IronPort-AV: E=Sophos;i="4.49,258,1262563200"; d="scan'208";a="231972477"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 11 Jan 2010 20:32:18 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0BKWIKp013194; Mon, 11 Jan 2010 20:32:18 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, 11 Jan 2010 12:32:18 -0800
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, 11 Jan 2010 12:32:18 -0800
Message-ID: <C0ACCB7B60E6F14B9AC46D742C1009A1C0F618@xmb-sjc-213.amer.cisco.com>
In-Reply-To: <4B47C5AD.6020204@informatik.uni-wuerzburg.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [lisp] LISP Interworking: Proxy Egress Tunnel Routers
Thread-Index: AcqQvfPcv7cADXebQCGrbD8d0pFoEQCOBobQ
References: <C0ACCB7B60E6F14B9AC46D742C1009A1C0F333@xmb-sjc-213.amer.cisco.com> <4B47C5AD.6020204@informatik.uni-wuerzburg.de>
From: "Darrel Lewis (darlewis)" <darlewis@cisco.com>
To: menth@informatik.uni-wuerzburg.de
X-OriginalArrivalTime: 11 Jan 2010 20:32:18.0858 (UTC) FILETIME=[2B8DE0A0:01CA92FD]
Cc: 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, 11 Jan 2010 20:32:21 -0000

 > 
> I do not understand the two application scenarios and how PETRs can 
> help. Could you explain that in more detail, please?
> 


Michael,

Today when an ITR receives a packet on its local interface with the
destination address of a non-lisp site, today it forwards it without
encapsulation.  To be specific, an ITR has a map-cache that contains
both 'positive' and 'negative' cache entries.  When a packet's
destination address matches a positive entry, it is encapsulated to the
locators in the mapping.  When a packet's destination address matches a
negative entry, the packet is forwarded natively without encapsulation
(to the next hop).

However, there are a couple of cases where this non-encapsulated packet
will get dropped.

First, the Provider Edge router may be doing some sort of strict
filtering on the source address of packets sent by the CE device (the
ITR).  Thus packets with the source of an EID may be dropped because the
PE router does not have an route to the EID out the interface.  

Second, the Provider Edge router may only support IPv4.  So an ITR
sending a IPv6 packet will obviously fail.

The Proxy ETR allows an ITR to encapsulate packets that match 'negative'
map-cache entries to a destination that can bypass both the above
situations.  In the first case, the encapsulated packet's outer header
has a correct source address.  In the second case, the encapsulated
outer header would be an IPv4 packet.  Of course, this implies that the
Proxy ETR has dual stack external connectivity (post decapsulation) the
Proxy ETR's upstream router(s) use loose mode uRPF.

Hope this helps explain the situation a little bit more clearly.

-Darrel