Subject: Re: [geonet/its] A possible geonet use-case

From: <[email-masked]>
Date: Mon, 6 Jan 2014 09:38:57 +0000

Hi Dino,

Thanks for the email and sorry for the delay!

I assume that the use case that you describe uses the LISP architecture and concepts, where according to RFC 6830:

"Routers continue to forward packets based on IP destination
   addresses.  When a packet is LISP encapsulated, these addresses are
   referred to as Routing Locators (RLOCs).  Most routers along a path
   between two hosts will not change; they continue to perform routing/
   forwarding lookups on the destination addresses.  For routers between
   the source host and the ITR as well as routers from the ETR to the
   destination host, the destination address is an EID.  For the routers
   between the ITR and the ETR, the destination address is an RLOC."

What is missing from your use case description is the fact that the End-systems (hosts) might not know the EID addresses.
What these end-systems could know is a geographic area where information needs to be sent to. So the end-system will need to have a way of translating the geographical area to EIDs, in addition to the LISP EID-to-RLOC Database.
How will you integrate this point into your use case description.

Best regards,
Georgios

From: its [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: zaterdag 14 december 2013 19:59
To: [email-masked]
Subject: [geonet/its] A possible geonet use-case

Folks, the chair of the 'its' BOF asked me to repost this use-case. I will try to describe it in a solution agnostic way. So apologize in advance for the slide that reads LISP on it.

The use-case described in the slide is a control-plane use-case only. There is no packet routing involved.

It is a way to use your existing network infrastructure investment and get more functionality out of it. Here is the basic idea:

(1) What you want to track has an IP address. It can be an opaque IP address and certainly not a Provider-Assigned IP address.

(2) The routers are configured with geo-coordinates (they are not required to have GPS receivers) of their physical location.

(3) When the tracked device appears to these routers, the IP address of the tracked device is associated with one more geo-coordinates of the routers.

(4) The routers can put this information in various types of databases.

One could see how a data-plane application could also extend this use-case.

Thanks,
Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 6 Jan 2014 12:02:03 -0800

> “Routers continue to forward packets based on IP destination
>    between the ITR and the ETR, the destination address is an RLOC.”
>  
>  

The Fedex package example is a control-plane play only. Because RLOCs are geo-coordinates which there is no packet format today to use them (no network layer). ;-)

In my use-case, the EIDs are not talking to each other. All the use-case is using is a mapping database to map EIDs to Geo-Coordinates. Where EIDs are Fedex tracking numbers and the RLOCs are the Geo-Coordinates.

> How will you integrate this point into your use case description.

Okay, so an data-path examples is in order. But this is a completely different use-case. So don't confuse them with the control-plane only Fedex use-case.

Here is a packet sequence where you can use Geo-Coordinates to select where packets are routed towards:

(1) Georgios, you are an EID. I want to send packets to you. I am an EID as well.
(2) I do a lookup in the LISP mapping database with a key "Georgios". What I get is a RLOC-set back as a reply from the mapping system.
(3) Let's say the RLOC-set contains 2 entries. Each entry is a 2-tuple of IP address of a LISP decapsulator and the Geo-Coordinates where it resides.
(4) The RLOC-set returns Geo-Coordinates for San Jose and Athens.
(5) I want to send packets to you via the San Jose xTR (that is the policy I want).

Dino

---

From: <[email-masked]>
Date: Tue, 7 Jan 2014 07:30:30 +0000

Hi Dino,

Thanks for the explanation.
I think that the use case that you proposed is very useful.
Actually in this use case you assume that you know the names (IDs) of a network entity (or end- host), which are the EIDs and need to find, via this mapping table the Geo-coordinates (and I assume also the IP address) of this network entity (or end-host).

The use cases that are described in the current version of the Internet-wide Geo-networking: Problem statement draft, assume that you know the geo-coordinates (your proposed RLOC; but without knowing the IP address) and via a mapping table need to find out the IP address (or name, e.g., EID) of the network entity (end-host). So actually is the reverse mapping of what your use case describes. 
This is very good, now we have use cases that justifies the use of forward  mapping from name (EID) to geo-coordinates (RLOC)) and reverse mapping from geo-coordinates (RLOC) to names (EID).

I think that your use case can be easily integrated in what we have up to now!

Furthermore, please note that challenges, that we need to also identify are the ones proposed by Dimitri Papadimitriou, can you please comment on these, please see email that I have sent yesterday with title: "challenges proposed by Dimitri"", which somehow address issues like: (1)  How can a geographic area be "represented", (2) which resolution mechanism to be used at the source (end-host), (3) which resolution mechanism can be used at the edges ( ITR and ETR), I assume the LISP based mapping in your use case?), (4) what is the rate and size of records populating the data base, (5) at which level of the protocol "stack" this mapping information needs to be inserted (in your use case I assume at the IP layer?)

Best regards,
Georgios

> -----Original Message-----
> From: Dino Farinacci [mailto:[email-masked]]
> Sent: maandag 6 januari 2014 21:02
> To: Karagiannis, G. (EWI)
> Cc: <[email-masked]>
> Subject: Re: [geonet/its] A possible geonet use-case
> 
> > Hi Dino,
> >
> > What is missing from your use case description is the fact that the End-
> systems (hosts) might not know the EID addresses.
> 
> The Fedex package example is a control-plane play only. Because RLOCs are
> geo-coordinates which there is no packet format today to use them (no
> network layer). ;-)
> 
> In my use-case, the EIDs are not talking to each other. All the use-case is
> using is a mapping database to map EIDs to Geo-Coordinates. Where EIDs are
> Fedex tracking numbers and the RLOCs are the Geo-Coordinates.
> 
> > What these end-systems could know is a geographic area where
> information needs to be sent to. So the end-system will need to have a way
> of translating the geographical area to EIDs, in addition to the LISP EID-to-
> RLOC Database.
> Okay, so an data-path examples is in order. But this is a completely different
> use-case. So don't confuse them with the control-plane only Fedex use-case.
> 
> (2) I do a lookup in the LISP mapping database with a key "Georgios". What I
> get is a RLOC-set back as a reply from the mapping system.
> (3) Let's say the RLOC-set contains 2 entries. Each entry is a 2-tuple of IP
> address of a LISP decapsulator and the Geo-Coordinates where it resides.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 7 Jan 2014 11:37:38 -0800

> Furthermore, please note that challenges, that we need to also identify are the ones proposed by Dimitri Papadimitriou, can you please comment on these, please see email that I have sent yesterday…

Here are some answers to questions (1) through (5):

(1) Geo-Coordinates are very much my IP prefixes. Degrees/Feet/Minutes can be used hierarchically. You can use combinations to defined a radius (a circular boundary), a triangle (as typical triangulation is used), or a square. And we can do longest match lookups on this 3-level hierarchy.

(2) An ITR could say "connect to Georgios EID via the closest ETR witin radius 10 degrees of Athens".

(3) Same as (2).

(4) That depends on so many things. We can discuss this at next IETF meeting perhaps.

(5) Network layer of course!

Dino