IETF Logo Mail Archive

Re: [nvo3] LISP control plane input into gap analysis draft

Sharon <sbarkai@gmail.com> Wed, 06 November 2013 12:51 UTC

Return-Path: <sbarkai@gmail.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CB221F9EA2 for <nvo3@ietfa.amsl.com>; Wed, 6 Nov 2013 04:51:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level:
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQgSL6H6y+90 for <nvo3@ietfa.amsl.com>; Wed, 6 Nov 2013 04:51:40 -0800 (PST)
Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id A7CEA21F9E9A for <nvo3@ietf.org>; Wed, 6 Nov 2013 04:51:40 -0800 (PST)
Received: by mail-qa0-f52.google.com with SMTP id ii20so1499078qab.18 for <nvo3@ietf.org>; Wed, 06 Nov 2013 04:51:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=9FiaP2StWe7HfTeo2dRF5Xp5dTKgRj7ofLUfMVEuwuk=; b=cNoaeIQvpLajUWfz+aluai7klhSXS5TyZ7KSHyrV8iRQT3fZ5lnxIfPrDtLvR5rLDv Ce/D2k8vdU/qUxoV3ijfYom8IYxGZl7rbYx4wwkS8RcQd/jfLiB2kqKEB1fIs41grUSh nMkjVtROzz6V/lBOxuer71C+uJMO+HiLlaIH/zUMbEDfah8kUre3ev/agDwZOISn1ujj JUh/a3GCBjpMiE8Is/jkeEQfNXCHBCV77Y/YLzOBbXD2b7p2WXhkfAznAxhVbJUeSFeV 7NjstIUo6sdZDefV1KXYpJ9hotwZkQjDYB6ceUSFNsPT9cw1y6ZLHT+E6O9OTm5ZYOtc kwPQ==
X-Received: by 10.236.124.172 with SMTP id x32mr1817309yhh.59.1383742300205; Wed, 06 Nov 2013 04:51:40 -0800 (PST)
Received: from [10.123.233.99] (mobile-166-147-108-122.mycingular.net. [166.147.108.122]) by mx.google.com with ESMTPSA id h66sm44460348yhb.7.2013.11.06.04.51.33 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 04:51:38 -0800 (PST)
References: <CE9DC147.26AC7%yhertogh@cisco.com> <C53D6243-6F77-431A-8A85-A6B7E87E9C03@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D452EA758@dfweml509-mbx.china.huawei.com> <EE890F7E-FE5A-4ABA-864D-D180060E64D3@gmail.com>
In-Reply-To: <EE890F7E-FE5A-4ABA-864D-D180060E64D3@gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"
Message-Id: <3EC7DC85-C919-4F90-B717-D65583810EC3@gmail.com>
X-Mailer: iPhone Mail (11B511)
From: Sharon <sbarkai@gmail.com>
Date: Wed, 06 Nov 2013 04:51:27 -0800
To: Dino Farinacci <farinacci@gmail.com>
Cc: Damien Saucez <damien.saucez@gmail.com>, "nvo3@ietf.org" <nvo3@ietf.org>, "Yves Hertoghs (yhertogh)" <yhertogh@cisco.com>, "draft-ietf-nvo3-gap-analysis@tools.ietf.org" <draft-ietf-nvo3-gap-analysis@tools.ietf.org>, Lucy Yong <lucy.yong@huawei.com>
Subject: Re: [nvo3] LISP control plane input into gap analysis draft
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nvo3>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Nov 2013 12:51:41 -0000

To add to Dino's comment, 
based on implementation experience (which can be referenced in ODL open source), at the physical to virtual network infrastructure definitions level.. 

a (lisp) re-tunneling element, with an underlay address and access to (cached) global mapping information.. can be used to:

- map flows to function chains by load and tenancy according to a specified (per source and or dest) itinerary, in a self balanced manner

- map flows to programable segmented paths in the underlay, for application aware core balancing e.g streamer accessing content real-time vs content being replicated in the background 

- replicate flows for multicasting to multiple rlocs, or for tapping / debugging / wiresharking / calea

Plus a few more utilities.
So LISP RTR is a recommended very practical "base-class"

--szb

> On Nov 4, 2013, at 2:00 PM, Dino Farinacci <farinacci@gmail.com> wrote:
> 

> Could someone explain to me how to use LISP solution to provide route path control? For example, in a VN, ingress NVE MUST forward the packets to another NVE at which a tenant system runs firewall software. The second NVE then forwards to the packets to the third NVE where an attached TS has the address that matches the destination address in the inner address on the packets.
> 
> Lucy

LISP has a decapsaltor/encasulator component called an RTR. An RTR can give you suboptimal paths by choice if you want to route around failures, congestion points, or use policy paths. You can find details in http://datatracker.ietf.org/doc/draft-farinacci-lisp-te.

But yes, you can have an RTR co-located with a firewall, laod-balancer, and NAT type middle devices.

Dino

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

v2.23.0 | Report a Bug | By Email