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

Dino Farinacci <farinacci@gmail.com> Wed, 07 September 2022 19:55 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368EAC15338F; Wed, 7 Sep 2022 12:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, FREEMAIL_FROM=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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4klgc6BeXoa; Wed, 7 Sep 2022 12:55:17 -0700 (PDT)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 6D5CCC15257E; Wed, 7 Sep 2022 12:55:17 -0700 (PDT)
Received: by mail-pf1-x42f.google.com with SMTP id b144so10888755pfb.7; Wed, 07 Sep 2022 12:55:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date; bh=9e2HnG0bw43niRIhfHOLw6dqKD87PCI0EyzEQR25y64=; b=XD7e0NmQ8j1XvaM1YUOaXEI5PQK+EZ2xdOEBg/UcMO9HSkLy0jWUIjDu5/kT0r7gV9 l8mR+3dDMUSQSzTc0liWDRaXPpZlzA3Ef5ADxe4GsaZQTC6l4BS6c8v8m6MwGGRKH8Q+ Vdmjx+7XD4jTahDVP9px2tlws1LJLaNAuV7BfBwREuwXesVSq7ERZucptIekODR13dAj o4WV7ewDalk6MPaujmnpSrA0mrNcwQN4L9UA1BWY9Rz423fD724bPZw8G7ZrMQB6FfZ2 RbBfp5eqLHT25PbMWCf9o3txqroXp41x34kRgwE35ECm1hbv+gWHu8s8g45W2ssZlcJC cX4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=9e2HnG0bw43niRIhfHOLw6dqKD87PCI0EyzEQR25y64=; b=oE+/evLMbWhaUFR5solMGYPKqos3ahKpr/lM06CVWtCGLdjk8yhpKncjV+iwNuq778 luiJTE2Or0QbuE4gj6ixHVF2QZ/6Fu4nBQaKHgHeLXjxTupofzV9s+rigxb48DJ7p0ow 1qp/yyf1vH8bZywYKz3iAPheCxZQ7yskSMx4Rboo545rLh0BswOnyiYg5pOcszSZ/mNS 4ABsGcX4Hzzqa0N4TkMHDt9gNGWfVGtFW+l69E/w00dkdxLVfiN0nLfkJiOTc1HeFdtn T/da9oe2DOAy+/zwAMFIo8NieZkuqibOQWlC7pVNE9rv9XO3j92pFuiwziTXSL1VDoex CZvw==
X-Gm-Message-State: ACgBeo0HqoVMfhi3I0NoYCzQSdxmEowqhBVFQrvGz/VMIKQaxVnJEF1T pFV6BrglsHig3VOI4sXp3Tg=
X-Google-Smtp-Source: AA6agR7Tozy9UkqvA+4miehNAsAUvAibex8rTd7NeCGjWwHHJCFrnlISwT1oNiJJhJjEdGzinw0dxQ==
X-Received: by 2002:a05:6a00:a19:b0:535:49ee:da43 with SMTP id p25-20020a056a000a1900b0053549eeda43mr5498989pfh.53.1662580516427; Wed, 07 Sep 2022 12:55:16 -0700 (PDT)
Received: from smtpclient.apple (c-98-234-33-188.hsd1.ca.comcast.net. [98.234.33.188]) by smtp.gmail.com with ESMTPSA id h15-20020a170902f54f00b001728ac8af94sm12867694plf.248.2022.09.07.12.55.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Sep 2022 12:55:15 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <2D3F7BF5-2E97-4C02-ADFC-732B92B94CCB@getnexar.com>
Date: Wed, 7 Sep 2022 12:55:14 -0700
Cc: Luigi Iannone <ggx@gigix.net>, "lisp@ietf.org list" <lisp@ietf.org>, lisp-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <85A59673-8137-44AF-86E4-E05FE8FB132A@gmail.com>
References: <ADCE3863-AF15-4C2A-84C9-CE2DB4186154@gmail.com> <2D3F7BF5-2E97-4C02-ADFC-732B92B94CCB@getnexar.com>
To: Sharon Barkai <sharon.barkai@getnexar.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/9pGqGRzYwLyWrVOxSXHmYenee1Q>
Subject: Re: [lisp] Call for Adoption: draft-farinacci-lisp-name-encoding-15.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Wed, 07 Sep 2022 19:55:21 -0000

Maybe to phrase the question this way to get more specific on the predictive-RLOC requirement. 

Lets take the client XTR first. Does it know its RLOC changes and do higher layers send an app packet? If that is the case, theg. RTR can learn/glean the change faster than the client xTR triggering a Map-Register (which in turn the RTR would be pubsub or have to TTL time out its map-cache entry quickly). 

Predictive RLOCs are useful at the expense of duplicating the same packets to multiple RLOCs taking a strategic guess which RLOC the EID is currently at.

As for the RTR RLOC frequently changing, what do the client XTRs have in their map-cache. Is it a 0.0.0.0/0 EID-prefix pointing to a set of RTR RLOCs? You will need pubsub to know when they change, if you can deal with messaging overhead to converge to the RLOC-change. You can also use anycast RLOCs where the 0.0.0.0/0 keeps encapsulating to the same RLOC and when an new RTR comes into range, it uses that RLOC. Very much how VRRP and HSRP work on a LAN.

Dino

> On Sep 6, 2022, at 6:30 PM, Sharon Barkai <sharon.barkai@getnexar.com> wrote:
> 
> Need to think about it. The active mapping use cases are more lenient than the conditions in the draft. Vehicles roam between cellular providers and P5G hotspots to save on data plan ($1/GB!!).
> 
> RTR RLOCs may change or remain, client EIDs change once in a while but for privacy not so much for roaming. Client XTR  (cXTR) RLOCs keep changing because of roaming. Its ok for Uploads because clients control that, but for security RTRs need to expect that. For notifications as well, RTRs need to expect cXTR RLOC changes for push notification replication. 
> 
> It relates to broader question  of:
> 
>  AAA   - Mapping
>           \       /
>           XTRs (clients, servers, aggregation)
> 
> For application routing top of fluid private-mobile-edge structure, but need to think more.
> 
> 
> --szb
> Cell: +972.53.2470068
> WhatsApp: +1.650.492.0794
> 
>> On Sep 6, 2022, at 19:54, Dino Farinacci <farinacci@gmail.com> wrote:
>> 
>> Sounds good. But I didn't realize your use-case application needed predictive-RLOCs. So I assume you have a requirement to do RLOC handoffs faster than the mapping system. True?
>> 
>> Dino
>> 
>>> On Sep 5, 2022, at 7:08 PM, Sharon Barkai <sharon.barkai@getnexar.com> wrote:
>>> 
>>> I agree.
>>> 
>>> Mobility, Anonymity, Predictive, AAA, VPN..
>>> All support private-mobile/mobile-edge issues.
>>> 
>>> LISP basics: given an EID and XTR(s), allow client interaction with a scoped set of EID objects, for a while. 
>>> 
>>> This solves the application server challenge of cloud to edge migration. Sourcing specific EID dest from client solves low east west capacity between fragmented edges (Gbps not Tbps).
>>> 
>>> In general application routing helps leverage 
>>> low cost, high north south, low east west (compared to carrier rings and cloud datacenter thick trees) .. of private-mobile-edge. LISP has the right base structure, hope wg adopts such charter themes.
>>> 
>>> 
>>> 
>>> --szb
>>> Cell: +972.53.2470068
>>> WhatsApp: +1.650.492.0794
>>> 
>>>>> On Sep 5, 2022, at 21:45, Dino Farinacci <farinacci@gmail.com> wrote:
>>>> 
>>>> I think we should revisit the charter. 
>>>> 
>>>> I would also like to give priority for working group drafts that have existed with no apparent direction for many years. Those include:
>>>> 
>>>> draft-ietf-lisp-mn                            (created 2009!)*
>>>> draft-ietf-lisp-te                            (created 2012)*
>>>> draft-ietf-lisp-map-server-reliable-transport (created 2014)
>>>> draft-ietf-lisp-yang                          (created 2015)
>>>> draft-ietf-lisp-eid-mobility                  (created 2016)*
>>>> draft-ietf-lisp-eid-anonymity                 (created 2016)
>>>> draft-ietf-lisp-predictive-rlocs              (created 2016)
>>>> draft-ietf-lisp-ecdsa-auth                    (created 2017)
>>>> draft-ietf-lisp-vpn                           (created 2017)*
>>>> 
>>>> I put a "*" in front of the ones I think should get priority. Note all the above documents are *not* use-case documents but protocol (mechanism) documents.
>>>> 
>>>> And we need to get some closure on NAT-traversal. At least make draft-ermagan-lisp-nat-traversal a working group document.
>>>> 
>>>> Thanks,
>>>> Dino
>>>> 
>>>>> On Sep 5, 2022, at 3:14 AM, Sharon Barkai <sharon.barkai=40getnexar.com@dmarc.ietf.org> wrote:
>>>>> 
>>>>> 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.
>>>>> 
>>>>> 
>>>>> --szb
>>>>> Cell: +972.53.2470068
>>>>> WhatsApp: +1.650.492.0794
>>>>> 
>>>>>>> On Sep 5, 2022, at 12:21, Luigi Iannone <ggx@gigix.net> 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 <ggx@gigix.net>, 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 <farinacci@gmail.com> 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: internet-drafts@ietf.org
>>>>>>>>> Subject: [lisp] I-D Action: draft-farinacci-lisp-name-encoding-15.txt
>>>>>>>>> Date: July 24, 2022 at 8:15:25 AM PDT
>>>>>>>>> To: <i-d-announce@ietf.org>
>>>>>>>>> Cc: lisp@ietf.org
>>>>>>>>> Reply-To: lisp@ietf.org
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 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:
>>>>>>>>> https://datatracker.ietf.org/doc/draft-farinacci-lisp-name-encoding/
>>>>>>>>> 
>>>>>>>>> There is also an htmlized version available at:
>>>>>>>>> https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-name-encoding-15
>>>>>>>>> 
>>>>>>>>> A diff from the previous version is available at:
>>>>>>>>> https://www.ietf.org/rfcdiff?url2=draft-farinacci-lisp-name-encoding-15
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> lisp mailing list
>>>>>>>>> lisp@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> lisp mailing list
>>>>>>>> lisp@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>>>> 
>>>>>> _______________________________________________
>>>>>> lisp mailing list
>>>>>> lisp@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>> _______________________________________________
>>>>> lisp mailing list
>>>>> lisp@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>> 
>>>> _______________________________________________
>>>> lisp mailing list
>>>> lisp@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/lisp
>> 
>> _______________________________________________
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp