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

From: Dino Farinacci <[email-masked]>
Date: Thu, 1 Aug 2019 10:00:52 -0700

I am still using this block but RIPE wants to remove it per IETF recommendations. Should we update RFC 7955 to indicate the “experiment” is still continuing?

Dino

> Begin forwarded message:
> 
> From: RIPE NCC Support <[email-masked]>
> Subject: #202719 - Re: LISP EID prefix 2001:5:3::/48
> Date: August 1, 2019 at 5:09:09 AM PDT
> To: farinacci <[email-masked]>
> Reply-To: RIPE NCC Support <[email-masked]>
> 
> ##- Please type your reply above this line -##
> Ticket (202719) has been updated. To add additional comments, reply to this email.
> 
> Mike Petrusha (RIPE NCC Support) 
> Aug 1, 14:09 CEST
> 
> Dear Colleagues,
> 
> The RIPE NCC have assigned LISP EID prefix 2001:5:3::/48 to lispers.net <http://lispers.net/> on 2016-11-16.
> 
> The assigned prefix will be removed on 31 August 2019.
> 
> According to RFC 7955, https://tools.ietf.org/html/rfc7955 <https://tools.ietf.org/html/rfc7955>
> "According to the 3+3 year experimentation plan, defined in
> [RFC 7954 <https://tools.ietf.org/html/rfc7954>], all registrations MUST end by August 2019, unless
> the IETF community decides to grant a permanent LISP EID
> address block."
> 
> 
> --
> Sincerely,
> 
> Mike Petrusha
> RIPE NCC
> 
> 
> This email is a service from RIPE NCC Support.
> [PMZV6Q-QO6Q]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 1 Aug 2019 13:46:54 -0400

I am presuming your phrasing is slightly misleading.  If you 
individually are the only user of the block, I do not see how we can 
justify asking RIPE to continue the assignment.

Yours,
Joel

On 8/1/2019 1:00 PM, Dino Farinacci wrote:
> I am still using this block but RIPE wants to remove it per IETF 
> recommendations. Should we update RFC 7955 to indicate the “experiment” 
> is still continuing?
> 
> Dino
> 
>> Begin forwarded message:
>>
>> *From: *RIPE NCC Support <[email-masked] <mailto:[email-masked]>>
>> *Subject: **#202719 - Re: LISP EID prefix 2001:5:3::/48*
>> *Date: *August 1, 2019 at 5:09:09 AM PDT
>> *To: *farinacci <[email-masked] <mailto:[email-masked]>>
>> *Reply-To: *RIPE NCC Support <[email-masked] <mailto:[email-masked]>>
>>
>> *Mike Petrusha*(RIPE NCC Support)
>>
>> Aug 1, 14:09 CEST
>>
>> Dear Colleagues,
>>
>> The RIPE NCC have assigned LISP EID prefix 2001:5:3::/48 tolispers.net 
>> <http://lispers.net/>on 2016-11-16.
>>
>> According to RFC 7955,https://tools.ietf.org/html/rfc7955
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 1 Aug 2019 11:33:15 -0700

No, its not about me. RIPE wants to stop allocating experimental EID blocks. Do we, the LISP WG, want that to happen?

Dino

> On Aug 1, 2019, at 10:46 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> I am presuming your phrasing is slightly misleading.  If you individually are the only user of the block, I do not see how we can justify asking RIPE to continue the assignment.
> 
> Yours,
> Joel
> 
>>> The RIPE NCC have assigned LISP EID prefix 2001:5:3::/48 tolispers.net <http://lispers.net/>on 2016-11-16.
>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 1 Aug 2019 14:36:08 -0400

If only one person is using the block after all this time, then yes, we 
as a working group want RIPE to stop allocating experimental EIDs.

If there is significant usage, then we should understand what it is and why.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 1 Aug 2019 11:38:38 -0700

> If only one person is using the block after all this time, then yes, we as a working group want RIPE to stop allocating experimental EIDs.

You are missing the point Joel. There are many sub-blocks allocated from the experimental block from RFC 7955. I am not the only sub-block.

> If there is significant usage, then we should understand what it is and why.

What if there is *any* usage for any subblock?

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 1 Aug 2019 14:40:56 -0400

We asked for an experiment.  As such, we need to re-evaluate the experiment.
You said "I am using it".   As I said, I presume that is a 
mis-statement.  Who is using EIDs from that block?  What are they being 
used for?  Is having a block actually helpful?

In particular, given that our focus as a working group has moved away 
from Internet-Wide deployments of LISP to more specialized use cases, it 
is not at all clear that the PS-to-be documents warrant the allocation.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 1 Aug 2019 11:51:12 -0700

> We asked for an experiment.  As such, we need to re-evaluate the experiment.

That is my point.

> You said "I am using it".   As I said, I presume that is a mis-statement.  Who is using EIDs from that block?  What are they being used for?  Is having a block actually helpful?

I am using EIDs out of the subblock that RIPE allocated to me. I have renewed the block each year. I can’t tell you who are using them without their permission. They are being used to be on an IPv6 overlay. They are being used with some structure in the address as well as crypto-EIDs.

Yes, having the block is useful. Especially was we will have a requirement to have these EIDs interwork with IPv6 Internet nodes.

> In particular, given that our focus as a working group has moved away from Internet-Wide deployments of LISP to more specialized use cases, it is not at all clear that the PS-to-be documents warrant the allocation.

I can’t see why it would be harmful to ask for another 3 years.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 2 Aug 2019 09:23:04 -0700

Mike, I have cc’ed the LISP WG in this response. Thanks for providing the active assignments.

As a member of the LISP WG, I would like to vote for an update to RFC 7955 to have the 2001:5::/32 block stay allocated until 2022.

Thanks Mike.

Dino

> On Aug 2, 2019, at 2:33 AM, RIPE NCC Support <[email-masked]> wrote:
> 
> Aug 2, 11:33 CEST
> Dear Dino,
> We sent a number of e-mails to LISP WG and received no reply still.
> 
> We are not sure if this reply will appear on the mailing list, if not, could you please forward it there.
> 
> With regards to the questions about number of assignments:
> as you can see at https://apps.db.ripe.net/db-web-ui/#/query?searchtext=-rMT%20inet6num%202001:5::%2F32 there are currently fouractive registrations within 2001:5::/32
> 
> Also, from https://www.ripe.net/ripe/mail/archives/lisp-announce/ you can see that another five assignments existed in the past and have either expired or were returned.
> 
> ----- Forwarded message -----
> 
> Date: Tue, 30 Jul 2019 09:34:31 +0200
> From: "RIPE NCC" <[email-masked]>
> To: Deborah Brungard <[email-masked]>,
>         Luigi Iannone <[email-masked]>,
>         Joel Halpern <[email-masked]>,
>         Padma Pillay-Esnault <[email-masked]>,
>         LISP WG <[email-masked]>
> Subject: LISP EID assignments from 2001:5::/32
> 
> 
> Dear LISP WG,
> 
> This e-mail is from the RIPE NCC, the Internet Registry in Europe.
> 
> The RIPE NCC provides temporary LISP EID assignments from LISP EID prefix 2001:5::/32 in accordance with RFC 7955: LISP EID Block Management, https://tools.ietf.org/html/rfc7955
> 
> We are contacting you as we are approaching August 2019, at which point we need to start removing existing LISP EID assignments within 2001:5::/32 (unless IETF made a decision to extend this period).
> 
> Following RFC 7955, https://tools.ietf.org/html/rfc7955
> [RFC 7954], all registrations MUST end by August 2019, unless
> In accordance with RFC 7954: LISP EID Block
> https://tools.ietf.org/html/rfc7954#section-6
> "  IANA allocated the requested address space in September 2016 for a
>    duration of 3 (three) years (through September 2019), with an option
>    to extend this period by 3 (three) more years (until September 2022).
>    By the end of the first period, the IETF will provide a decision on
>    whether to transform the prefix into a permanent assignment or to put
>    it back in the free pool..."
> 
> Could you please let us know whether such decision was made by the IETF?
> 
> 
> According to https://tools.ietf.org/html/rfc7954#section-7
> "  In order to trigger the process for a permanent allocation, a
>    document is required.  Such a document has to articulate the
>    rationale for why a permanent allocation would be beneficial.  More
>    specifically, the document has to detail the experience gained during
>    experimentation and all of the technical benefits provided by the use
>    of a LISP-specific prefix. "
> 
> Could you please let us know if such document was created?
> 
> 
> According to https://tools.ietf.org/html/rfc7954#section-7
> "  If no explicit action is carried out by the end of the experiment (by
>    September 2019), it is automatically considered that there was not
>    sufficient interest in having a permanent allocation; therefore, the
>    address block will be returned to the free pool."
> 
> Based on this, the RIPE NCC is ready to proceed with removing existing LISP EID assignments within 2001:5::/32 in August 2019 (as defined by RFC 7955) and returning 2001:5::/32 to the IANA in September 2019 (as defined by RFC 7954).
> 
> We await your reply.
> 
> 
> --
> Sincerely,
> 
> Mike Petrusha
> RIPE NCC
> 
> 
> 
> farinacci
> Aug 1, 19:00 CEST
> 
> The RIPE NCC have assigned LISP EID prefix 2001:5:3::/48 to lispers.net on 2016-11-16.
> 
> According to RFC 7955, https://tools.ietf.org/html/rfc7955
> [RFC 7954], all registrations MUST end by August 2019, unless

---

From: Sharon <[email-masked]>
Date: Fri, 2 Aug 2019 20:58:46 +0300

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 draft-lisp-nexagon, is allocated unique EID.

This allows for interoperable connectionless session layer - publish (ucast) and subscribe (mcast) sharing - of geo-state via EID addressable broker. Formal EID brokers enable real-time enumeration of road safety-defects-furniture, verified and shared multi-vendor while protecting sources privacy.

There are ~5B H3 resolution 9 hexagons on earth out of which ~1% need to be addressable, 50M EID networked hexagons.
We allocated a sub-block of 2001:5::/32 EID experimental for this purpose, 64bit H3 IDs mapped algorithmically to 128bit EIDs.

Extending the draft will help leveraging the network for real-time public-safety using addressable brokering for better verification, privacy, and secure linear (vs polynomial) interoperability effort. 

--szb
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794

> On Aug 2, 2019, at 7:23 PM, Dino Farinacci <[email-masked]> wrote:
>