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 <[email protected]> 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 <[email protected]> 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 
>>> <[email protected]> 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 <[email protected]> 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 <[email protected]>, 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 <[email protected]> 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: [email protected]
>>>>>>> Subject: [lisp] I-D Action: draft-farinacci-lisp-name-encoding-15.txt
>>>>>>> Date: July 24, 2022 at 8:15:25 AM PDT
>>>>>>> To: <[email protected]>
>>>>>>> Cc: [email protected]
>>>>>>> Reply-To: [email protected]
>>>>>>> 
>>>>>>> 
>>>>>>> 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
>>>>>>> [email protected]
>>>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>>> 
>>>>>> _______________________________________________
>>>>>> lisp mailing list
>>>>>> [email protected]
>>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>> 
>>>> _______________________________________________
>>>> lisp mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/lisp
>>> _______________________________________________
>>> lisp mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/lisp
>> 
>> _______________________________________________
>> lisp mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/lisp

_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to