Re: [lisp] Call for Adoption: draft-farinacci-lisp-name-encoding-15.txt

Sharon Barkai <> Mon, 05 September 2022 10:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9334CC15256F for <>; Mon, 5 Sep 2022 03:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 2zdJkjPOF3SH for <>; Mon, 5 Sep 2022 03:14:17 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 73AB2C1522A8 for <>; Mon, 5 Sep 2022 03:14:17 -0700 (PDT)
Received: by with SMTP id p16so16052060ejb.9 for <>; Mon, 05 Sep 2022 03:14:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:content-transfer-encoding:from:to:cc:subject:date; bh=IkWumKLLk1jkplfs7g3Bx7OS5l5dwZRlvynFiRV24Sk=; b=GrXjOmnoPwEwaFPT5DHNkeZad+qKlv6kiD+Zks8DXc37gEq+ntPq+mCkVWsrI8eAIJ YV5D+7DvSmL/e2OMDYuDnoEKbUvwTm2EgSbRkZvTZZMCIHtNIkgCMq/yMfO1Fq7kqK1j Ijg5V/Tp3eLIGKdrfTk81iCmWaYwJTUcs+v98=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:content-transfer-encoding:x-gm-message-state:from:to :cc:subject:date; bh=IkWumKLLk1jkplfs7g3Bx7OS5l5dwZRlvynFiRV24Sk=; b=aLCTukEOemhBKTOV8bifE5S9B0Lv9eO34Dlp4MQfXGAghMBTUuBtXl5RHlQmAiI6qY a+3BdyKFV8ghMJ4kNlCPrXVs8pft3+BlWLEGrH+2qpSAJCKMz8qG9MCZzyo74RXNpOGx h5aCVpAVqE2JJbef+/zVddhpPWTKT15qPr8aie67TYvgr4TdW3Lr1ROtg/3FrNJI5zGu YE6cmXQrO+ay2LMuW0UEgF6fRyg8rbmrHwxYCaZwVsUS25ayo9VTaduuePCyKhomBqBN IpXkk6WuSkwbVDOepCBpVnN9xMMeUf9IQGnPVdC84WRU/8giHxIav5VdjpQimvIDXHGw dx/g==
X-Gm-Message-State: ACgBeo1azBM6pl2aZy7UNHegdq8cjCjvpJE4Vaflg5ZvuX1Ks47se2JR kJljZsp2IN3zx62AEX2gcE3QcA==
X-Google-Smtp-Source: AA6agR4nRAQk6VPxjal9Q9kMzWyfVsfuHCNe/fIC3PbP5gGxNgOQXYpVw+TBauOiBKIpW2WOIOYUeg==
X-Received: by 2002:a17:907:720b:b0:731:6e49:dc93 with SMTP id dr11-20020a170907720b00b007316e49dc93mr35982199ejc.421.1662372855675; Mon, 05 Sep 2022 03:14:15 -0700 (PDT)
Received: from ([]) by with ESMTPSA id cz19-20020a0564021cb300b0044780b6debasm6271423edb.32.2022. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Sep 2022 03:14:15 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-B5D35323-AB98-4E55-B7DB-6121FCF5EBD3"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Sharon Barkai <>
In-Reply-To: <e50a7a25-8c8d-4b1c-a428-90076fe08c7d@Spark>
Date: Mon, 05 Sep 2022 13:14:13 +0300
Cc: " list" <>,
Message-Id: <>
References: <e50a7a25-8c8d-4b1c-a428-90076fe08c7d@Spark>
To: Luigi Iannone <>
X-Mailer: iPhone Mail (19G82)
Archived-At: <>
Subject: Re: [lisp] Call for Adoption: draft-farinacci-lisp-name-encoding-15.txt
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Sep 2022 10:14:21 -0000

On a related Note. Wanted to bring up next move on the charter. I think we can all agree that addressable naming like in lisp-nexagon H3 EIDs is part of lisp application edge routing theme that is already active in the wg. This is timely in light of private mobile, and mobile edge compute trends and gaps.

There are many reasons to factor compute from cloud to edge, latency, capacity, regulation, but mostly cost. There is a very high centralization tax in cloud vs edge as far as margins and energy/cooling bills that can be saved. However its not easy to factor workloads from cloud to edge:

1) before any client API reaches an edge service it should be “TSA Pre-checked” who what where this client is and that this specific edge server can address this specific query right now. This is without compromising client privacy and security as there is no wall of application servers shielding clients from services. Neither  is there east-west pinball between fragmented micro services across edge location. LISP routing per named logical addressing for both clients and services are very applicable.

2) any edgefied service has to be able to encapsulate logic and state units in portable manner, allow  for elastic allocation across edge servers. During peaks less units per server and more edge locations, and visa verse. There is also need for quick recovery from locations (fragmanted) failures. In this context what comes to mind for edge cloud migration is factoring to edge anything digital-twin. In that sense nexagons are just one example of road-tile twin. And again LISP named routing steering quickly between failed or overflow locations by name location mapping and separation.   

Wonder what is the chairs, group thinking here.

Cell: +972.53.2470068
WhatsApp: +1.650.492.0794

> On Sep 5, 2022, at 12:21, Luigi Iannone <> wrote:
> Hi All,
> This call for adoption was open for a while now and there were several emails in support of the adoption.
> As such, there is a clear consensus in adopting this document.
> The authors are invited to submit a new version of the document renamed as WG item.
> Thanks to all people that expressed their opinion.
> Ciao
> L.
>> On 5 Aug 2022 at 17:22 +0200, Luigi Iannone <>, wrote:
>> Hi All,
>> The authors of the lisp-name-encoding draft (see below) have requested working group adoption for this document.
>> This email starts a three weeks call for working group adoption of this document.
>> Please respond, positively or negatively.  Silence does NOT mean consent.  
>> Please include explanation / motivation / reasoning for your view.
>> Thank you,
>> Luigi & Joel
>>> On 24 Jul 2022, at 17:17, Dino Farinacci <> wrote:
>>> We have made changes to -15 to address Joel's comments. Thanks to Marc and Joel for their participation and cooperation.
>>> I would like to, at this time, request for this draft to be a working group document. I will present the status and changes to -15 at the LISP WG.
>>> Cheers,
>>> Dino
>>>> Begin forwarded message:
>>>> From:
>>>> Subject: [lisp] I-D Action: draft-farinacci-lisp-name-encoding-15.txt
>>>> Date: July 24, 2022 at 8:15:25 AM PDT
>>>> To: <>
>>>> Cc:
>>>> Reply-To:
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>> This draft is a work item of the Locator/ID Separation Protocol WG of the IETF.
>>>>        Title           : LISP Distinguished Name Encoding
>>>>        Author          : Dino Farinacci
>>>>  Filename        : draft-farinacci-lisp-name-encoding-15.txt
>>>>  Pages           : 9
>>>>  Date            : 2022-07-24
>>>> Abstract:
>>>>   This draft defines how to use the AFI=17 Distinguished Names in LISP.
>>>> The IETF datatracker status page for this draft is:
>>>> There is also an htmlized version available at:
>>>> A diff from the previous version is available at:
>>>> Internet-Drafts are also available by rsync at
>>>> _______________________________________________
>>>> lisp mailing list
>>> _______________________________________________
>>> lisp mailing list
> _______________________________________________
> lisp mailing list