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
