Re: [Ideas] [lisp] IDEAS @IETF98 Minutes

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2922513F3F4; Wed, 25 Oct 2017 08:13:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ue3zxxavTtdF; Wed, 25 Oct 2017 08:13:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A939F13F3D0; Wed, 25 Oct 2017 08:13:47 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 87E9D460160; Wed, 25 Oct 2017 08:13:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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
Received: from Joels-MacBook-Pro.local (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id A147F2407FB; Wed, 25 Oct 2017 08:13:46 -0700 (PDT)
To: Sharon <>, Padma Pillay-Esnault <>
Cc:, NVO3 <>, LISP mailing list list <>,
References: <> <>
From: "Joel M. Halpern" <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Ideas] [lisp] IDEAS @IETF98 Minutes
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.