[lisp] lisp-nexagon consolidated vision

A simple diagram of a lisp h3 eid based network for an all terrain/conditions shared and consolidated vision. Network formed by many moving producers for many moving consumers, interoperability, Geo privacy, and scaling based on lisp ucast/mcast and h3 eids alone. No shared libs. Each lisp

Re: [lisp] I-D Action: draft-ietf-lisp-nexagon-52.txt

ol (LISP) WG of the IETF. > > Title: Network-Hexagons:Geolocation Mapping Network Based On H3 and LISP > Authors: Sharon Barkai >Bruno Fernandez-Ruiz >Rotem Tamir >Alberto Rodriguez-Natal >Fabio Maino >Alber

Re: [lisp] LISP minutes - IETF 117 San Francisco

“Alvaro: It would be nice to have a document that gives ideas and talk about deployment model or scenarios. Versus having documents from the WG on how to use LISP on datacenters, satellites, cars, airplanes, etc. Those documents don't change LISP, they tell you how to use it. If that is what

Re: [lisp] I-D Action: draft-ietf-lisp-nexagon-45.txt

Title : Network-Hexagons:Geolocation Mobility Edge Network > Based On H3 and LISP >Authors : Sharon Barkai > Bruno Fernandez-Ruiz > Rotem Tamir > Alberto Rodrigue

Re: [lisp] LISP PubSub to Proposed Standard?

++ --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Dec 8, 2022, at 18:02, Dino Farinacci wrote: > >  >> >> Hi Luigi, all, >> >> I also think that it is reasonable to publish this spec as a proposed >> standard. > > +1. > > Dino >

[lisp] Fwd: New Version Notification for draft-barkai-lisp-pems-06.txt

-Aparicio , Alberto Rodriguez-Natal > , Dino Farinacci , Fabio Maino > , Sharon Barkai > Subject: New Version Notification for draft-barkai-lisp-pems-06.txt > >  > A new version of I-D, draft-barkai-lisp-pems-06.txt > has been successfully submitted by Sharon Barkai and posted to th

Re: [lisp] Fwd: Lisp Portable Edge Multipoint Sockets

lti-Tuple draft.I am not sure who you are referring to but I know a lot of people that use eBPF. You should google for a list name and propose they review the document and definitely invite them to IETF.DinoBegin forwarded message:From: Sharon Barkai <sharon.bar...@getnexar.com>Subject: Re: Lis

Re: [lisp] Lisp Portable Edge Multipoint Sockets

https://datatracker.ietf.org/doc/html/draft-barkai-lisp-pems > On Nov 21, 2022, at 20:33, Dino Farinacci wrote: > > Yes, everything you can define the better. Even a "socket" since its an > overloaded term. Plus you want to define terms based on how the document is > going to use them. So

Re: [lisp] New Version Notification for draft-barkai-lisp-pems-01.txt

Cell: +972.53.2470068WhatsApp: +1.650.492.0794On Nov 20, 2022, at 18:25, internet-dra...@ietf.org wrote:A new version of I-D, draft-barkai-lisp-pems-01.txthas been successfully submitted by Sharon Barkai and posted to theIETF repository.Name:        draft-barkai-lisp-pemsRevision:    01Title:        Portable

Re: [lisp] Supporting lisp-geo [Was: Re: lisp - Requested session has been scheduled for IETF 115]

I agree Fabio, it is well written! However, if it will become at some point acceptable to submit drafts in bullets, along with masks and headers, and flow diagrams (still pure currier) , it will make life a lot easier for non native english speakers :) --szb Cell: +972.53.2470068 WhatsApp:

Re: [lisp] Call for adoption for LISP Geo-Coordinate Use-Cases

Support of course. --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Oct 29, 2022, at 14:43, Luigi Iannone wrote: > > Folks, > > The author of the document LISP Geo-Coordinate Use-Cases did ask the chairs > to open a call for adoption. > > You can find the document at: >

Re: [lisp] LISP Specifications Published!! :-)

Congratulations! --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Oct 21, 2022, at 02:51, Alberto Rodriguez-Natal (natal) > wrote: > >  > Time to celebrate! Huge thank you and congratulations to everyone! > > Alberto > > From: lisp on behalf of Fabio Maino (fmaino) > >

Re: [lisp] lisp - Requested session has been scheduled for IETF 115

Dear Chairs, Would like to give update on ietf-lisp-nexagon progress since Vienna: 1) H3 EID LCAF specification added 2) H3geo.org and BDD reviews and fixes - calculating H3EID from H3 detection ID - enumerating frequently changing signs 3) Public AECC PoC by Nexar, KDDI, Oracle - detect

Re: [lisp] LISP WG Re-Chartering discussion

> On Oct 7, 2022, at 02:31, Alvaro Retana wrote: > > On October 6, 2022 at 12:55:28 PM, Dino Farinacci wrote: > > > Hi! > >>> I think that is the place to say that we will also work on relevant >>> Informational and Experimental work. >> >> I definitely agree with this statement. > > >

Re: [lisp] LISP WG Re-Chartering discussion

“ LISP aims for an incrementally deployable protocol. The scope of the LISP technology is potentially applicable to have a large span, including unicast and multicast overlays at Layer 2 as well as at Layer 3, encompassing NAT traversal, VPNs”, or application specific networks. “supporting

Re: [lisp] I-D Action: draft-ietf-lisp-nexagon-41.txt

With pleasure! --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Sep 30, 2022, at 00:40, Dino Farinacci wrote: > > Sharon, just an FYI, get ready to change occurences of RFC6830 to RFC9300. > > Dino > >> On Sep 29, 2022, at 4:20 AM, Sharon Barkai >>

Re: [lisp] WG Last Call: draft-ietf-lisp-name-encoding-00.txt

Support.--szbCell: +972.53.2470068WhatsApp: +1.650.492.0794On Sep 28, 2022, at 21:16, Alberto Rodriguez-Natal (natal) wrote: Support. As I mentioned during WG adoption, this doc is just making explicit something that was implicit :)   Alberto   From: lisp on behalf of Luigi Iannone

Re: [lisp] I-D Action: draft-ietf-lisp-nexagon-40.txt

ork > Based On H3 and LISP >Authors : Sharon Barkai > Bruno Fernandez-Ruiz > Rotem Tamir > Alberto Rodriguez-Natal > Fabio Maino >

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

u 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 wrote: >>

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

ote: > > 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 wrote: >> >> I agr

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

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 >> wrote: >> >> On a related Note. Wanted to bring up next move on the charter. I t

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

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

Re: [lisp] I-D Action: draft-ietf-lisp-nexagon-37.txt

n H3 and LISP >Authors : Sharon Barkai > Bruno Fernandez-Ruiz > Rotem Tamir > Alberto Rodriguez-Natal > Fabio Maino > Albert Cabellos-Aparicio >

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

Support as well. Name based routing supports a wide range of use-cases and association between clients and services that does not stall for DNS, avoids mass client-cache incoherency by concentrating mappings in-network, using well defined, interoperable and optimized lisp mapping system. It

Re: [lisp] H3 steering committee review on draft-ietf-lisp-nexagon-36

Dear Isaac and H3 Steering Committee, Thank you very much again for the detailed thoughtful review of drat-ietf-lisp-nexagon. Will try to incorporate most of your comments already in the next draft. Bellow please find authors comments. Once again thank you for the work! H3 Steering Review

[lisp] Fwd: Review of the LISP-NEXGON draft

c: Fisher Yu , Sharon Barkai , Bruno > Fernandez-Ruiz > Subject: Review of the LISP-NEXGON draft > >  > Dear LISP@IETF.org, > > This is a review of the draft available at > https://datatracker.ietf.org/doc/html/draft-ietf-lisp-nexagon by Prof. Trevor > Darrell of UC Ber

Re: [lisp] H3 steering committee review on draft-ietf-lisp-nexagon-36

Thank you Isaac and the H3 steering committee team. I am forwarding to the lisp list to expedite till external mail is cleared by list moderator. I will address the excellent points raised in this very constructive review on the list and in fixes in the next draft. Thanks again, Sharon

[lisp] H3 Steering Committee review of draft-ietf-list-nexagon-36

H3geo will also send directly to the list. The BDD review is due soon also - academia on summer schedule. H3 Steering Committee review of draft-ietf-list-nexagon-36.pdf Description: Adobe PDF document --szb Cell: +972.53.2470068 WhatsApp:

Re: [lisp] New Version Notification for draft-farinacci-lisp-satellite-network-00.txt

The problem is that i don't know too much about these new sat networks. They are supposed to offer coverage for undeveloped areas. Connecting UE xTRs, to proper internet router xTR. Maybe the operator wants to keep them as simple as possible or as IP relays. So potentially yes, no lookups,

Re: [lisp] New Version Notification for draft-farinacci-lisp-satellite-network-00.txt

: +1.650.492.0794 > On Apr 2, 2022, at 18:44, Dino Farinacci wrote: > >  >> >> Hi Dino, > > Thanks for the comment Sharon. > >> Im not sure if it makes sense, but when we were in the satellite IP session >> in IETF, >> it was explained that: >> &g

Re: [lisp] Fwd: New Version Notification for draft-farinacci-lisp-satellite-network-00.txt

Hi Dino, Im not sure if it makes sense, but when we were in the satellite IP session in IETF, it was explained that: - as satellite routers move around in orbit - each assumes RLOC of sky sector its in So it can be simple for a ground station XTR, to source plot the shortest sky grid path.

Re: [lisp] LISP Nexar comment 2

u state what mechanisms in LISP deliver those features. I think you have > done that in the drafts. > > Dino > >>> On Nov 12, 2021, at 5:02 PM, Sharon Barkai >>> wrote: >>> >>> >>> >>>> On Nov 12, 2021, at 15:04, Dino Farinac

Re: [lisp] LISP Nexar comment 2

> On Nov 12, 2021, at 15:04, Dino Farinacci wrote: > >> 6. Both lisp-nexagon and lisp-fix do not change the protocol. But you do >> have to understand the map assisted overlay ucast/mcast > > I don't understand what you mean. Say more please. I mean, if you didn't know LISP, you would need

Re: [lisp] LISP Nexar comment 2

1. The Edge Geolocation Services EIDs have a 64bit H3-ID part of the location of the Vehicle being served 2. This is how we eliminate the need for an actual geospatial network. These are virtualized in the form of H3EIDs 3. The prefix of the service EID is the H3 location it serves, the

[lisp] Use of Distributed Computing for Mobility Services in an AECC System - Automotive Edge Computing Consortium

LISP benefits in multi-provider layering-curating-reducing the massive mobility uploads, are important. Interoperable layering enables geo-privacy, service-continuity, identity-preservation for ledgers-integrity, non-trivial load-balancing .. when moving vehicle EIDs communicate with

Re: [lisp] LISP WG @ IETF 111th - Minutes available

Following up on action item to poll for wg interest in lisp-(in)fix wg draft .. Introduction: Compute First Networking (CFN) goal is to fuse compute and networking in order to process data locally, close to where its generated - while allowing for global awareness, a compilation of all

Re: [lisp] Call for agenda items

is discovered each week in each site. The question is if there is group motivation to standardize such a lisp-fix sampling overlay interface: - to be supported by switches, routers, vswitches - as well as eBPF and other OSs standard network extensions. Thank You, Sharon --szb Cell: +972.53.2470068

Re: [lisp] I-D Action: draft-ietf-lisp-nexagon-07.txt Last Call

tem of the Locator/ID Separation Protocol WG of the > IETF. > >Title : Network-Hexagons: H3-LISP GeoState & Mobility Network >Authors : Sharon Barkai > Bruno Fernandez-Ruiz > S Z

Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon

. --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Feb 8, 2021, at 12:05, Albert López wrote: > >  > Hi Sharon, > > Thanks for your clarifications. I have some questions inline. > >> On 5/2/21 13:31, Sharon wrote: >> Thank you Albert. These a

Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon

Thank you Albert. These are very good comments. See inline: --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Feb 5, 2021, at 12:26, Albert López wrote: > >  > Hi all, > > After reading the draft, I believe it is a really good idea, but I think that > the document needs more work

Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon

Thank you Luigi Joel. We are working to add LISP based digital-twin interface for road segments to the AECC auto-edge. The roll of this interface is to throttle the pipes: car access to edge, edge to cloud by: 1. Recording car EID data-handles in tile EID ledgers for selective uploads per

Re: [lisp] WG Last Call for draft-ietf-lisp-pubsub

Support! I think LISP as shown you can build overlays without resorting to circuit-switched controllers by using the mapping system. This mechanism makes the mapping effect quicker to respond to changes by adding pub-sub proven scalability. --szb Cell: +972.53.2470068 WhatsApp:

[lisp] Lisp-Coin touch points

https://www.ietf.org/proceedings/109/slides/slides-109-coinrg-19-piccolo-summary-00.pdf As you can see this project has many cogs right. The reverse CDN is key in few respects: - Its about use-cases that bring value at any density and therefore will probably precede high density low-latency

Re: [lisp] [secdir] Secdir early review of draft-ietf-lisp-nexagon-04

. (And sorry > about the email issues and associated delays.) > > On 10/20/20 1:34 AM, Sharon Barkai wrote: >>>> On Oct 20, 2020, at 02:34, David Mandelberg >>>> >>> <mailto:david=40mandelberg@dmarc.ietf.org>> wrote: >>> >>

Re: [lisp] [secdir] Secdir early review of draft-ietf-lisp-nexagon-04

> On Oct 20, 2020, at 02:34, David Mandelberg > wrote: > > (I previously sent the email below on 2020-10-10, but I don't think it went > through due to an email server misconfiguration. Sending again now that my > email issues are fixed, I think) Made it! > > On

Re: [lisp] Secdir early review of draft-ietf-lisp-nexagon-04

if you think the concerns are addressed. All the best, Sharon > On Oct 8, 2020, at 23:21, Tero Kivinen via Datatracker > wrote: > > Reviewer: David Mandelberg > Review result: Not Ready > > I have reviewed this document as part of the security directorate's > ong

Re: [lisp] Secdir early review of draft-ietf-lisp-nexagon-04

Sorry for the confusion, David! really want to thank you for putting in the time, you clearly understood the draft completely and point to areas we invested thought on but can improve the wording. Before adjusting the draft would like to rehash together with the group, Joel, and Luigi the

Re: [lisp] Secdir early review of draft-ietf-lisp-nexagon-04

Tero, really want to thank you for putting in the time, you clearly understood the draft completely and point to areas we invested thought on but can improve the wording. Before adjusting the draft would like to rehash together with the group, Joel, and Luigi the themes pointed, which are

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

Support. --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Sep 27, 2020, at 10:36, Dino Farinacci wrote: > > I did not see any objections for this request but I didn’t see any specific > support either. Can we get some replies if you support this. Otherwise, it > will continue to

[lisp] Lisp 108 meeting comments

Just wanted to say that the meeting was very short, and perhaps make a couple suggestions 1. LISP NAT Traversal This is an important problem which is inherent from the fact that rlocs are a stored in the map server-resolver and not just in the data-path. I think we need a full interim and

Re: [lisp] Support draft-nexagon wg adoption

t; naturally with LISP and addresses a hugely important networking requirement > for continuously roaming mobility clients. > > As such, I endorse the draft to be published as an informational RFC. > > -b > >> On 19 Nov 2019, at 06:36, Sharon Barkai wrote: >> >&

[lisp] Support draft-nexagon wg adoption

Hey, following very productive session today and as discussed would like to formally ask group for draft adoption. Cheers, Sharon --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman

Re: [lisp] [Call for Agenda Items] IETF 106 Preliminary Agenda

Hi Luigi, for Singapore would like to allocate time for motion to move draft-nexagon to workgroup items: update on progress since 105, and, allow non-author / non-wg from internet industry opportunity to express / debate support reasoning. Thanks in Advance, Sharon --szb Cell: +972.53.2470068

[lisp] Fwd: New Version Notification for draft-barkai-lisp-nexagon-11.txt

> , " sbar...@gmail.com" , "S > ZionB" , "Dino Farinacci" , > "Albert Cabellos-Aparicio" , "Sharon Barkai" > , "Bruno Fernandez-Ruiz" , "Sharon > Barkai" , "Fabio Maino" > Subject: New Version Notificat

Re: [lisp] 5G deployment status (was: Re: [ipwave] I-D Action: draft-barkai-lisp-nexagon-10.txt)

20/09/2019 à 04:23, Sharon Barkai and Dick Roy ([RR]) wrote: > [...] >>> */[RR] This is a really long story, however, C-V2X is being specified as an >>> alternative to US DSRC, not as a cellular access technology since that’s >>> already available and deployed. The re

Re: [lisp] [ipwave] I-D Action: draft-barkai-lisp-nexagon-10.txt

real problem you’re trying to solve and one > you’ve thought about hard. I may (*may*) be able to make time to look at it > properly over the next while. > > Cheers, > > William > > From: Sharon Barkai > Sent: Thursday, September 19, 2019 3:06 PM > To: William Why

Re: [lisp] [ipwave] I-D Action: draft-barkai-lisp-nexagon-10.txt

: +1.650.492.0794 > On Sep 19, 2019, at 10:05 PM, Sharon Barkai > wrote: > > Thank you William. > > Sorry if my summary did some injustice to the DSRC spec trying to account for > the adaptation challenges and the budgets considered necessary by gov-muni. > > But I think you

Re: [lisp] [ipwave] I-D Action: draft-barkai-lisp-nexagon-10.txt

EEE WAVE device architecture) leave it as an implementation choice. I agree > that the existing standards don’t fully address this issue, though. > > Hope this corrects some misunderstandings. > > Cheers, > > William > > > > > > > From: its On Beha

Re: [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt

t > curious. > > Regards, > Stan > > From: lisp On Behalf Of Sharon Barkai > Sent: Thursday, September 19, 2019 1:30 AM > To: Victor Moreno (vimoreno) > Cc: lisp@ietf.org > Subject: Re: [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt > > ***WARNING! THIS EMAI

Re: [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt

Thank you Victor. Quick recap of mobility networks evolution: 1. Couple of decades ago a peer to peer layer2 protocol called DSRC was specified over WiFi spectrum with basic safety messages (BSM) in which cars conveyed their GPS and kinematics sensor events like hard-brake, sharp-turn.

[lisp] Fwd: New Version Notification for draft-barkai-lisp-nexagon-10.txt

: +1.650.492.0794 Begin forwarded message: > From: internet-dra...@ietf.org > Date: September 16, 2019 at 11:46:17 AM GMT+3 > To: "Alberto Rodriguez-Natal" , " sbar...@gmail.com" > , "S ZionB" , "Dino Farinacci" > , "Albert Cabellos-Aparicio"

[lisp] Fwd: New Version Notification for draft-barkai-lisp-nexagon-07.txt

--szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 Begin forwarded message: > From: internet-dra...@ietf.org > Date: September 8, 2019 at 9:34:41 AM GMT+3 > To: "Alberto Rodriguez-Natal" , " sbar...@gmail.com" > , "S ZionB" , "Dino Farinacc

[lisp] Fwd: New Version Notification for draft-barkai-lisp-nexagon-06.txt

--szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 Begin forwarded message: > From: internet-dra...@ietf.org > Date: September 1, 2019 at 11:17:57 AM GMT+3 > To: "Alberto Rodriguez-Natal" , " sbar...@gmail.com" > , "S ZionB" , "Dino Farinacc

Re: [lisp] #202719 - Re: LISP EID prefix 2001:5:3::/48

Dino, Mike, if ok would like to add to this important thread - One practical use of LISP EIDs which is being deployed in US cities and major metropolitans is that of IP addressable shared geo-states. In these use-cases each geo-cell in a formal grid of the earth, for example H3 resolution 9 in

[lisp] Agenda IETF105: hotrfc

Fyi we will pitch the need for EID addressable geo-states to broker connectionless mobility communications at layer3-4 in hotRFC. https://datatracker.ietf.org/doc/agenda-105-hotrfc/ --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 ___ lisp

[lisp] Fwd: New Version Notification for draft-barkai-lisp-nexagon-04.txt

--szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 Begin forwarded message: > From: internet-dra...@ietf.org > Date: May 22, 2019 at 10:49:08 AM GMT+3 > To: "Alberto Rodriguez-Natal" , "Sharon Barkai" > , "S ZionB" , "Dino > Farinacci

Re: [lisp] New Version Notification for draft-barkai-lisp-nexagon-03.txt

we can hear what the workgroup thinks about it, so we can anticipate the timeline by which we can address the market need for a layered open standard. Thank you in advance for your consideration, meanwhile we will continue working it. All the best, Sharon --szb Cell: +972.53.2470068 WhatsApp

[lisp] Fwd: New Version Notification for draft-barkai-lisp-nexagon-00.txt

Begin forwarded message: > From: internet-dra...@ietf.org > Date: February 5, 2019 at 11:19:49 AM GMT+2 > To: "Alberto Rodriguez-Natal" , "Ohad Serfaty" > , "Fabio Maino" , "Albert > Cabellos-Aparicio" , "Sharon Barkai" > >

Re: [lisp] The LISP WG has placed draft-rodrigueznatal-lisp-pubsub in state "Call For Adoption By WG Issued"

++ --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Apr 4, 2018, at 9:15 AM, Alberto Rodriguez-Natal > wrote: > > As author, I support adoption. This extension will be very welcome. > > Alberto > >> On Tue, Apr 3, 2018 at 6:26 PM, Joel M. Halpern

Re: [lisp] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt

Can add that we don't want to scale a mapping service like dns or x500. rather take full advantage of no-sql tech that wasn't available at the time to create a flat pub-nub like service for overlays, scaled based on underlay regular IP. No bootstrap loop. The effect on mobile can be dramatic,

Re: [lisp] Lisp for 5G

Will take a look. Thanks! --szb On Aug 28, 2016, at 9:11 AM, Dino Farinacci wrote: >> Maybe we should go in a draft through all the mechanisms, multi home, bits, >> Smr .. >> specifically in the context of handover >> Perhaps a heads up message from the mobile device is

Re: [lisp] Lisp for 5G

Maybe we should go in a draft through all the mechanisms, multi home, bits, Smr .. specifically in the context of handover Perhaps a heads up message from the mobile device is needed before fully moving from ETR to ETR ... --szb > On Aug 27, 2016, at 12:34 PM, Dino Farinacci

Re: [lisp] [nvo3] OpenOverlayRouter released!

++ Overlays probably the most sustainable artifact of network virtualization trend. Good to distill distinct overlay notions into practical code base combining them. Further build from there in parallel to formal interface standardization. --szb > On Feb 5, 2016, at 6:53 AM, MORTON, ALFRED C

Re: [lisp] Update Proposed CHarter

I agree with Dino, will pull up (1) though, it allows carriers to anchor access services in POPs where the MAO operations are based. Cloud RAN, NFV, VPN .. type services. --szb On Jan 4, 2016, at 11:49 AM, Dino Farinacci wrote: >> If the text looks good for you, please

Re: [lisp] Draft of new Proposed Charter

We could say that as we completed a set of experimental lisp rfcs the importance of connectionless logical services networks overlaying and or anchoring topological IP networks grew significantly. To accommodate we continue to evolve the unique lisp map-assisted overlay architecture

Re: [lisp] LISP Overlay Model

other. However, the data-plane is not as flexible. The current specifications allow only IPv4 over IPv6 and vice versa. In order to create what Sharon Barakai defined “map assisted overlays” more work is needed. In this context the WG should also decide whether just an extended/enhanced data

Re: [lisp] LISP Use Cases

would also say that if we are to help implement overlays with the lisp mapping architecture, then we could expect any overlay aggregation node to subscribe to any traffic identifiers/classifiers - unicast, multicast.g, taps, chain.index.. and to the mappings them selves Doesn't mean they get

Re: [lisp] Lisp l2 VPN

Thanks!!! So that's why we couldn't find it. Good to see common sense in writing :) --szb On Jul 8, 2015, at 11:12 PM, Fabio Maino fma...@cisco.com wrote: Hi Sharon, the latest version is in https://datatracker.ietf.org/doc/draft-maino-nvo3-lisp-cp/ After the recharter discussion, I

[lisp] Lisp l2 VPN

Sorry for the repeat queries.. What is the latest draft available (Maino)? What's the ARP best practice, ARP Mediation or IPLS ARP Proxy ? It looks like the ARP Mediation RFC is used only to carry RLOC MACs not endpoint MACs. Not sure why, ARP FlowHandler + Mapping scales to end points ..

[lisp] Lisp to Nvo3

In the short re-charter discussion there was a proposal to offer lisp architecture (with multi encapsulations option) as one of the possible control planes for nvo3. There was a comment regarding inter-networking with legacy vpn. We recently faced such a requirement for service

Re: [lisp] [EXTENDED] draft-saucez-lisp-impact-07 - Call for WG Adoption

++ for 1 --szb On Dec 22, 2014, at 09:43, Victor Moreno (vimoreno) vimor...@cisco.com wrote: + 1 Victor On Dec 22, 2014, at 10:51 AM, Dino Farinacci farina...@gmail.com wrote: I like option (1) and think the document should be adopted. Dino On Dec 22, 2014, at 7:12 AM, Joel M.

Re: [lisp] Comparing LISP multicast with draft-ghanwani-nvo3-app-mcast-framework-01.txt

I think it's important to point out that all these features which require in-network anchoring e.g. multicast replication, mobility/motion, chaining, NAT traversal, anycast ... in lisp, use ONE consistent methodology - a floating anchor in the mapping database can be unambiguously resolved

[lisp] Fwd: New Version Notification for draft-barkai-lisp-nfv-05.txt

-Aparicio acabe...@ac.upc.edu, Alberto Rodriguez-Natal arna...@ac.upc.edu, Vina Ermagan verma...@cisco.com, Dino Farinacci farina...@gmail.com, Albert Cabellos-Aparicio acabe...@ac.upc.edu, Sharon Barkai sbar...@gmail.com, David Meyer d...@1-4-5.net, Vina Ermagan verma...@cisco.com, Alberto

Re: [lisp] WG Last Call on draft-lisp-introduction-07

Also agree, excellent overall intro to the lisp two tier network architecture and the possibilities opened by it. I found one typo :) --szb On Oct 25, 2014, at 12:07 PM, Marc Binderberger m...@sniff.de wrote: Hello Luigi and list members, A lot of work has been done lately on

Re: [lisp] I-D Action: draft-ietf-lisp-introduction-06.txt

--szb On Oct 23, 2014, at 09:31, internet-dra...@ietf.org internet-dra...@ietf.org wrote: 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 Working Group of the IETF. Title

Re: [lisp] New Version Notification for draft-saucez-lisp-impact-06.txt

: Dear all, As the impact draft aims at documenting operational points, we would be happy to have some feedback from people. From the discussions and mails, we identified that some of you could directly help in the document, more precisely, in addition to Sharon: - Ron on the change

Re: [lisp] [nvo3] Rechartering update

Hi Alia, --szb On Oct 2, 2014, at 10:47 AM, Alia Atlas akat...@gmail.commailto:akat...@gmail.com wrote: Hi Fabio, On Thu, Oct 2, 2014 at 1:40 PM, Fabio Maino fma...@cisco.commailto:fma...@cisco.com wrote: Alia, what's the rationale of adding LISP to the last sentence? Is it expected that

Re: [lisp] Fwd: I-D Action: draft-ietf-lisp-introduction-05.txt

Albert, is there a way to generalize the problem statement a bit. Eg explain the rapidly reduced correlation between IP address prefixes and the location of end points in the network. A problem that started with increased fragmentation and disaggregation of BGP subnets, has increased due to

Re: [lisp] Fwd: New Version Notification for draft-saucez-lisp-impact-06.txt

Hi Damian, our experience applying the lisp architecture is focused on service providers network under the umbrella of what we call Lisp Flow Mapping - Subscriber to Services . Is this domain of interest to your impact document? If so will be happy to help. The Lisp Flow Mapping use cases

Re: [lisp] Authentication for LISP-OE

We have a distributed resolver ( MR as a DHT function) implementation option. So still lisp compliant, but single hop, no extra lookup overhead. It's for when the overlay nodes (XTR+DHT or NVE/NVA) trust each other just do not trust the Underlay. --szb On Sep 2, 2014, at 10:59, Rene Bartsch

Re: [lisp] Restarting last call on LISP threats

for the clarification. --szb On May 27, 2014, at 7:17 AM, Ronald Bonica rbon...@juniper.net wrote: Hi Sharon, We may be talking about an XTR that is sick due to a bug or attack. We may also be talking about an attacker that isn't an XTR at all, just impersonating one

Re: [lisp] Restarting last call on LISP threats

Joel, thanks for clearing. It was hard to follow. If the challenge is for a distributed mapping system to keep track and protect itself from a sick xTR, sick because of a bug or an attack.. Then perhaps we could maintain mapping lookup per sec counters per xTR in the mapping. It adds some

Re: [lisp] Welcome a new co-chair

Congratulations. --szb On Mar 18, 2014, at 7:58, Brian Haberman br...@innovationslab.net wrote: All, For those of you who have not noticed, I have added Luigi Iannone as a third co-chair. I want to thank Luigi for agreeing to take on this role. Apologies for not announcing

Re: [lisp] LISP SDN

Have to say that I agree with Lori on that point. It's possible to specify a flow based lisp, ie cached-lookup, pub-sub, as Dino says very accurately and consequently all around efficient low-cost, low-footprint hardware, high performance software on generic hardware implementation... All

Re: [lisp] LISP SDN

LISP Pattern Matching Hashing Caching :) --szb On Feb 18, 2014, at 8:02 AM, Dino Farinacci farina...@gmail.com wrote: I was thinking a draft title that incorporates flow would probably be suitable, since you're extending LISP to deal with L4 flows. I was almost going to suggest

Re: [lisp] Short name for DFZ?

Underlay ? --szb On Oct 21, 2013, at 12:20 PM, Noel Chiappa j...@mercury.lcs.mit.edu wrote: Hi, I was asked to kill all uses of the term DFZ in the Intro document, and was advised to replace it with the term Internet core. However, DFZ is used a _lot_, and having Internet core really gets

Re: [lisp] No LISP meeting for Berlin

really don't want to interrupt this great dialog, just one comment. don't think is about a bigger address space for routing, but rather combining 2 completely different lookup schemes. Step1: you lookup the routing location of Mr. Smith, or Mr. Li, or Herr Meier or Mr. Dupont in a huge ID

Re: [lisp] I-D Action: draft-iannone-lisp-eid-block-mgmnt-01.txt

On Mar 4, 2013, at 10:30 AM, Dino Farinacci farina...@gmail.com wrote: The question is to try to avoid the complexities of a hybrid private/public. The same ones we see with cloud infrastructures right now. Don't think there is a way around dealing with this issue of long-jumps between

Re: [lisp] draft-ietf-lisp-architecture: Demand Loading of Mappings

2cents .. in most compute task pull is by far the preferred method for distributing information. specifically in networking pull has 2 issues: 1. latency - this can be mitigated by pull per flow rather then per packet, its app aware caching 2. bootstrap - you have to be able to reach the element