Subject: [Ideas] GRIDs is a necessary use-case for LISP and HIP

From: Dino Farinacci <[email-masked]>
Date: Thu, 20 Jul 2017 02:14:12 -0700

As one of the original coauthors of LISP, I just want to say the IDEAs effort will be well served for the locator/id split protocols. I think all overlay protocols can make use of a *network-layer* based database. And since security has to be a number 1 priority requirement, we have to create something new.

When I say “new”, I mean to create an operational infrastructure where the loc/id split control protocols can be deployed at scale. We have an application level database, it is called DNS. We need a network-layer database.

I think people should view GRIDs not for what use-cases it can provide, but how to define a deployment strategy for a network-layer database infrastructure for the use-cases that LISP, HIP, ILA, and ILNP *already* provide.

Dino

---

From: Jungha Hong <[email-masked]>
Date: Thu, 20 Jul 2017 15:10:58 +0000

Dear all,

I attended in the BoF yesterday and I agree with the Dino's comment that we need a network-layer database.

Actually, in my project, we have desined and implemented a mapping system between ID and locator(s) especially for supporting a flat typed ID efficiently. It was designed as a network-layer database.

Thanks,

Jungha Hong

________________________________
보낸 사람 : "Dino Farinacci" <[email-masked]>
보낸 날짜 : 2017-07-20 18:14:24 ( +09:00 )
받는 사람 : [email-masked] <[email-masked]>
참조 :
제목 : [Ideas] GRIDs is a necessary use-case for LISP and HIP

Dino

_______________________________________________

Ideas mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/ideas

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 20 Jul 2017 08:13:29 -0700

> Actually, in my project, we have desined and implemented a mapping system between ID and locator(s) especially for supporting a flat typed ID efficiently. It was designed as a network-layer databas…

Jungha, if you can share, it would be nice to hear some detailed properties of the database. I’m particulary interested on your pubsub scalability.

Thanks,
Dino

---

From: Jungha Hong <[email-masked]>
Date: Thu, 20 Jul 2017 15:42:24 +0000

For scalability, we had to take the tree structure for the mapping system like DNS.

But our contribution was how to update/lookup (pub/sub) the locator(s) by a flat typed ID which is registered in somewhere on the mapping system.

I would like to introduce our mapping system as one of the solutions for a flat typed ID in the IDEAS meeting when it is possible.

Thanks,

Jungha Hong

________________________________
보낸 사람 : "Dino Farinacci" <[email-masked]>
보낸 날짜 : 2017-07-21 00:13:38 ( +09:00 )
받는 사람 : 홍정하 <[email-masked]>
참조 : [email-masked] <[email-masked]>
제목 : Re: [Ideas] GRIDs is a necessary use-case for LISP and HIP

Thanks,

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 20 Jul 2017 10:40:41 -0700

> For scalability, we had to take the tree structure for the mapping system like DNS.

Like the LISP WG did for LISP-DDT (RFC8111).

> But our contribution was how to update/lookup (pub/sub) the locator(s) by a flat typed ID which is registered in somewhere on the mapping system.

My pubsub related questions is this. If something else publishes an entry, and I look it up, cache it, will the mapping system notify me when the mapping changes?

> I would like to introduce our mapping system as one of the solutions for a flat typed ID in the IDEAS meeting when it is possible.

That would be great. Thanks for sharing.

Dino

---

From: Hesham ElBakoury <[email-masked]>
Date: Fri, 21 Jul 2017 09:28:51 +0000

Hi Dino,

Are you suggesting to use LISP/HIP control protocol for IDEAS ?

Thanks

Hesham

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Thursday, July 20, 2017 2:14 AM
To: [email-masked]
Subject: [Ideas] GRIDs is a necessary use-case for LISP and HIP

Dino

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Fri, 21 Jul 2017 11:43:26 +0200

Hi Hesham

Please check slides of PS that will give you better perspective.

Thanks
Padma

Sent from my iPhone

> On Jul 21, 2017, at 11:28, Hesham ElBakoury <[email-masked]> wrote:
> 
> Hi Dino,
>

---

From: Hesham ElBakoury <[email-masked]>
Date: Fri, 21 Jul 2017 10:39:31 +0000

Thanks Padma,

I looked at the PS slides and now I have better understanding of the PS and I agree with the approach we will be using to address 
IDEAS control protocol.

Hesham

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Padma Pillay-Esnault
Sent: Friday, July 21, 2017 2:43 AM
To: Hesham ElBakoury
Cc: [email-masked]; Dino Farinacci
Subject: Re: [Ideas] GRIDs is a necessary use-case for LISP and HIP

Hi Hesham

Thanks
Padma

Sent from my iPhone

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 21 Jul 2017 13:04:52 +0100

> Are you suggesting to use LISP/HIP control protocol for IDEAS ? 

Well as a mature candidate, it should be considered. 

Dino

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 25 Jul 2017 09:33:46 -0400

I am just starting to go through the mails since the BOF.  It will take 
a couple days, so please bare wtih me here.

I both agree and disagree.

There are three values we need to 'track' and have access via any of them:

Identity:  This is a higher layer value that generally tags an Entity 
but is not what is used in actual communication protocols. It is a label 
that generally defines the Entity and MAY be human understandable, or 
only machine understandable.  There needs to be extensive policy control 
on who/what can see an Identity and gain access to the Identities meta 
data (like what services provided).

Identifier:  This is a communications label.  It needs to be represented 
in a manner that aligns with communication protocols, but is not of 
necessity a part of every communication packet.  Tight format is 
desirable and something that is 'well understood' by applications in 
working with communications.  This is why I view a major Identifier 
format that of an IPv6 address.  There is still policy around 
Identifier; primarily rights to query and Identifier and learn its 
Location, Identity, and meta data.  Expect to see Identifiers embedded 
in protocols like FTP PASV and HTTP Redirects; thus the need of the 
Identifer to Identity and Location lookup. This retrieval should be 
quick, but not needs to be network speed.

Location:  This is an IP address of an Entity's Interface.  It is how 
packets physically reach an Entity.  the Identifier/Location is the 
portion that operates at the network and needs network performance 
optimization.  But there can still be policy here; just because a packet 
is trageted to an Identifier does not give the Source automatic 
privileges to its Location.  The lookup is fast, but gated.  The 
Location/Identity pairing is again informational, not directly used in 
communications.

All told, all query types need to work well and be policy gated. The 
Identifier to Location needs to be fast.  All needs security and policy.

We will get to working on the requirements for the system and well 
delineating the roles and such.

Bob

On 07/20/2017 11:10 AM, Jungha Hong wrote:
> Actually, in my project, we have desined and implemented a mapping 
> system between ID and locator(s) especially for supporting a flat 
> typed ID efficiently. It was designed as a network-layer database.
>
>
> Thanks,
>
> Jungha Hong
>
>
> ------------------------------------------------------------------------
> *보낸 사람 : *"Dino Farinacci" <[email-masked]>
> *보낸 날짜 : *2017-07-20 18:14:24 ( +09:00 )
> *받는 사람 : [email-masked] <[email-masked]>
> *참조 : *
> *제목 : *[Ideas] GRIDs is a necessary use-case for LISP and HIP
>
> As one of the original coauthors of LISP, I just want to say the IDEAs 
> effort will be well served for the locator/id split protocols. I think 
> all overlay protocols can make use of a *network-layer* based 
> database. And since security has to be a number 1 priority 
> requirement, we have to create something new.
>
> When I say “new”, I mean to create an operational infrastructure where 
> the loc/id split control protocols can be deployed at scale. We have 
> an application level database, it is called DNS. We need a 
> network-layer database.
>
> I think people should view GRIDs not for what use-cases it can 
> provide, but how to define a deployment strategy for a network-layer 
> database infrastructure for the use-cases that LISP, HIP, ILA, and 
> ILNP *already* provide.
>
> Dino
>

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Tue, 25 Jul 2017 08:56:56 -0700

Hi Robert

On Tue, Jul 25, 2017 at 6:33 AM, Robert Moskowitz <[email-masked]>
wrote:

> I am just starting to go through the mails since the BOF.  It will take a
> couple days, so please bare wtih me here.
>
>
I will be going through a similar exercise this week to ensure we have much
of the BOF information on the list.

> Identity:  This is a higher layer value that generally tags an Entity but
> is not what is used in actual communication protocols.  It is a label that
> generally defines the Entity and MAY be human understandable, or only
> machine understandable.  There needs to be extensive policy control on
> who/what can see an Identity and gain access to the Identities meta data
> (like what services provided).
>

I would also add that this information should be protected if exchanged on
the wire.

> necessity a part of every communication packet.  Tight format is desirable
> and something that is 'well understood' by applications in working with
> communications.  This is why I view a major Identifier format that of an
> IPv6 address.  There is still policy around Identifier; primarily rights to
> query and Identifier and learn its Location, Identity, and meta data.
> Expect to see Identifiers embedded in protocols like FTP PASV and HTTP
> Redirects; thus the need of the Identifer to Identity and Location lookup.
> This retrieval should be quick, but not needs to be network speed.
>
>
It should be clarified that it is possible to have policies and metadata
tied to identity and identifier independently. We have not specifically
discussed whether the identity policy applies or is inherited naturally to
all its identifiers but that is a thought.

> packets physically reach an Entity.  the Identifier/Location is the portion
> that operates at the network and needs network performance optimization.
> But there can still be policy here; just because a packet is trageted to an
> Identifier does not give the Source automatic privileges to its Location.
> The lookup is fast, but gated.  The Location/Identity pairing is again
> informational, not directly used in communications.
>
>
Isn't this policy just plain IP policies as we know it today?

Would be preferable tp distinguish this from policy per se by calling it
access control on look up .. There is a subtle difference between policy
and the way lookup are gated or respond "unknown". It would be wise if the
response is indistinguishable from "does not exist".

> Identifier to Location needs to be fast.  All needs security and policy.
agree

> delineating the roles and such.
Have you checked the requirements document yet?

Thanks
Padma

> Actually, in my project, we have desined and implemented a mapping system
> between ID and locator(s) especially for supporting a flat typed ID
> efficiently. It was designed as a network-layer database.
>
>
> Thanks,
>
> Jungha Hong
>
>
>
>
>
> ------------------------------
> *보낸 사람 : *"Dino Farinacci" <[email-masked]> <[email-masked]>
> *받는 사람 : [email-masked] <[email-masked]> <[email-masked]>
> *참조 : *
> effort will be well served for the locator/id split protocols. I think all
> overlay protocols can make use of a *network-layer* based database. And
> since security has to be a number 1 priority requirement, we have to create
> something new.
>
>
>
>
> When I say “new”, I mean to create an operational infrastructure where the
> loc/id split control protocols can be deployed at scale. We have an
> application level database, it is called DNS. We need a network-layer
> database.
>
>
>
>
> I think people should view GRIDs not for what use-cases it can provide,
> but how to define a deployment strategy for a network-layer database
> infrastructure for the use-cases that LISP, HIP, ILA, and ILNP *already*
> provide.
>
>
>
>
> Dino
>
>
>
>
>
>
> Ideas mailing [email-masked]://www.ietf.org/mailman/listinfo/ideas
>
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 25 Jul 2017 10:16:37 -0700

Bob, I can go along with your definition but with one reservation, the statement "but is not of necessity a part of every communication packet”. I think the language may be too strong. 

Because if this is not necessary then what would go in an IPv6 header, regardless if there were one or two headers in the packet (i.e. considering no encap versus encap, respectively). 

You might be saying that if locators are placed in the IPv6 header, then what identifies a transport connection can be something in the transport header (TP4 had T-selector, HIP could use API, etc). Is this what your getitng at?

Dino

> On Jul 25, 2017, at 6:33 AM, Robert Moskowitz <[email-masked]> wrote:
> 
> I am just starting to go through the mails since the BOF.  It will take a couple days, so please bare wtih me here.
> 
> Identity:  This is a higher layer value that generally tags an Entity but is not what is used in actual communication protocols.  It is a label that generally defines the Entity and MAY be human understandable, or only machine understandable.  There needs to be extensive policy control on who/what can see an Identity and gain access to the Identities meta data (like what services provided).
> 
> Identifier:  This is a communications label.  It needs to be represented in a manner that aligns with communication protocols, but is not of necessity a part of every communication packet.  Tight format is desirable and something that is 'well understood' by applications in working with communications.  This is why I view a major Identifier format that of an IPv6 address.  There is still policy around Identifier; primarily rights to query and Identifier and learn its Location, Identity, and meta data.  Expect to see Identifiers embedded in protocols like FTP PASV and HTTP Redirects; thus the need of the Identifer to Identity and Location lookup.  This retrieval should be quick, but not needs to be network speed.
> 
> Location:  This is an IP address of an Entity's Interface.  It is how packets physically reach an Entity.  the Identifier/Location is the portion that operates at the network and needs network performance optimization.  But there can still be policy here; just because a packet is trageted to an Identifier does not give the Source automatic privileges to its Location.  The lookup is fast, but gated.  The Location/Identity pairing is again informational, not directly used in communications.
> 
> All told, all query types need to work well and be policy gated.  The Identifier to Location needs to be fast.  All needs security and policy.
> 
> We will get to working on the requirements for the system and well delineating the roles and such.
> 
> Bob
> 
>