Re: [lisp] IDEAS @IETF98 Minutes

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 25 October 2017 15:13 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: routing-discussion@ietfa.amsl.com
Delivered-To: routing-discussion@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2922513F3F4; Wed, 25 Oct 2017 08:13:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ue3zxxavTtdF; Wed, 25 Oct 2017 08:13:47 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A939F13F3D0; Wed, 25 Oct 2017 08:13:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 87E9D460160; Wed, 25 Oct 2017 08:13:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1508944427; bh=MRs/LV3BcnotPN+9F219xsr+m6bkbw0jA3rNzmHjDl4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=AM0YuCsAXPdjqIE51gW+R+bPEAHqoP7asqoPIlbmae9Up0QqoVW0ZVDz9ZJ8mWwN2 4cBPuPZWibdYmZyPWTxBQV+Io67BdpuzCr9poIzV2nplaW0FW4FaQ8ovS/S0eA568/ ZUuFixyNzG8MgujQQJjoF8XVfxDDcCrOTACvtsqQ=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [97.65.134.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A147F2407FB; Wed, 25 Oct 2017 08:13:46 -0700 (PDT)
Subject: Re: [lisp] IDEAS @IETF98 Minutes
To: Sharon <sbarkai@gmail.com>, Padma Pillay-Esnault <padma.ietf@gmail.com>
Cc: ideas@ietf.org, NVO3 <nvo3@ietf.org>, LISP mailing list list <lisp@ietf.org>, routing-discussion@ietf.org
References: <CAG-CQxogviqXizpwsdZpvjLQ9yw+Vx04HBEaq6+AuMr8TyjxdQ@mail.gmail.com> <C5C9119F-9378-473D-9E61-A6D86405547E@gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <c94e0e76-14e3-4442-a4cc-c3cd081a6130@joelhalpern.com>
Date: Wed, 25 Oct 2017 11:13:45 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <C5C9119F-9378-473D-9E61-A6D86405547E@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/routing-discussion/Xa2I33y_zEbShM68C_o7j_Xy01E>
X-BeenThere: routing-discussion@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area General mailing list <routing-discussion.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/routing-discussion>, <mailto:routing-discussion-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/routing-discussion/>
List-Post: <mailto:routing-discussion@ietf.org>
List-Help: <mailto:routing-discussion-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/routing-discussion>, <mailto:routing-discussion-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Oct 2017 15:13:54 -0000

Regarding the second of your two points, I am not following you:

On 10/11/17 8:00 PM, Sharon wrote:
> Discussed these 2 ID networking items with Albert and others, perhaps 
> this is a good thread:
> 
...
> 
> 2. Lisp-Lambda -
> A serverless (or virtual-appliance-less) alternative to service function 
> chaining which is hard to scale and dev-ops. Its done by mapping flows 
> at the ITR, ETR, or STR (segment) to queues, and using the mapping to 
> invoke the (cached) function on the flow queue packets rather then hair 
> pining the packets in and out of function virtual appliances. Saves 
> nic-ram-nic-ram... costly lifting.
> 

I am not asking why or how one can use LISP to direct traffic.  I 
understand that.
Rather, the description of service function chaining is veyr confusing.
1) One of the points of SFC is to direct packets to virtual service 
functions.  We are not mandating virtual service functions, but rather 
enabling their use when operators want to use them.  A technique that 
avoids such direction would seem to prevent such usage, defeating the point.
2) NSH (and more generally SFC) can be used to direct traffic on paths 
that do not happen to touch any service functions.  If the service 
function path goes through a sequence of service function forwarders, 
but does not actually visit any service functions, nothing is violated.

So while I have no problem with using LISP for chaining (either using 
LISP mapping to drive NSH SFPs or using LISP multi-hope technology for 
the data plane) I find the explanation you provided avoce confusing.

Yours,
Joel