## Administration   {#administration}

Pillay-Esnault/Iannone  
Agenda Bashing

Chairs: Request from LISP PubSub authors to give brief update after
presentations already on the agenda.

## WG Items   {#wg-items}

### Network-Hexagons:Geolocation Mobility Edge Network Based On H3 and LISP   {#network-hexagonsgeolocation-mobility-edge-network-based-on-h3-and-lisp}

*   https://datatracker.ietf.org/doc/draft-ietf-lisp-nexagon/  
    10 Minutes (Cumulative Time: 15 Minutes)  
    Sharon Barkai

No Questions.

## Non WG Items   {#non-wg-items}

### LISP Geo-Coordinate Use-Cases   {#lisp-geo-coordinate-use-cases}

*   https://datatracker.ietf.org/doc/draft-farinacci-lisp-geo/  
    10 Minutes (Cumulative Time: 35 Minutes)  
    Dino Farinacci

**Chairs:** There is a call for adoption that is open in this moment. If
you support this document please sent an email on the mailing list.

**Alvaro Retana:** The format is the same as OSPF and BGP. Those drafts
didn't go anywhere mostly because people were concerned about publishing
location. If the working group wants to work on this I can't stop you,
but be conscious of that there's going to be a lot of questions around
privacy.

**Alavaro Retana:** There's RFC 6973 called privacy considerations for
internet protocols and what we probably want to do is besides or maybe
instead of what the security section says actually have a privacy
considerations so that when people look at this they're going to
immediately jump there. Distinguish it from the security considerations
section. Some people make it a subsection or a completely different
sectionto to track the attention of people that want to look at this.

**Dino Farinacci:** What you register the mapping system about location
can be static things like everybody knows where Charles de Gaulle
Airport is and where Paris.  
To assign geo-coordinates to routers and and hosts and things, that's a
completely different matter.

**Alvaro Retana:** There are many use cases there are probably fine and
there are probably use cases that are not.

**Dino Farinacci:** It depends on who sees the location and what they
could do with it. Now the mapping system can restrict map requests. In
the ECDSA draft you can sign map requests and and then you can know
exactly who is requesting it and they can be authorized.

**Alvaro Retana:** Those things you want to put in the privacy
considerations: the way you limit who can see this information.

**Padma Pillay-Esnault:** We are talking about different kind of
families of what can be like for example Charles de Gaulle or other
public buildings or places. We can actually group those in very specific
instances. You can actually have a class of objects that are already
known, so there's no privacy.

**Dino Farinacci:** We can use instance IDs. If you want to publish
yourself in to the mapping system and you want to be public and you
don't care where your location is, then you register it to a specific
instance ID. If you want privacy, you register to a different IID, which
is severely restricted.

**Padma Pillay-Esnault:** Special emergency response can be a really
good use case, where you actually want to know the location but only
certain people can actually look them.

**Dino Farinacci:** You can obfuscate it or aggregate it. You don't have
to give your geo point, you can give a geo fence that's 20 kilometers
and you're somewhere in there.

**Sharon Barkai:** Do you know if we can combine geo EIDs with ephemeral
EIDs and sort of handle the Privacy.

**Dino Farinacci:** You can have EIDs that are ephemeral in terms of how
long they exist in a mapping system and if you want to keep being known
to be in a location you have to keep generating new ones. You send a map
register with a short timeout and when it times out the map server will
just remove them. We can do this with existing machinery.

### LISP for Satellite Networks   {#lisp-for-satellite-networks}

*   https://datatracker.ietf.org/doc/draft-farinacci-lisp-satellite-network/
    
    10 Minutes (Cumulative Time: 25 Minutes)  
    Dino Farinacci

**Dino Farinacci:** SHould we make this draft a WG document?

**Luigi Iannone:** Does this document extends or modifies the LISP
specifications in any way?

**Dino Farinacci:** It is documenting the fact that LISP can run over a
satellite Network and it requires no changes to the architecture.

**Luigi Iannone:** This document has not been discussed on the mailing
list. WOuld be good if some discussion takes place before considering
adoption.

**Dino Farinacci:** I can start the discussion.

**Lin Han:** \[slide 10\] When the satellite link dish is changing do
you trigger any update on the xTR to EID binding?

**Dino Farinacci:** No. What happens in the diagram \[slide 10\] is that
EID2 is registered with the RLOC of the GS-xTR, which is the IP address
of the wireless interface to the Wi-Fi router. When the EID2 moves it's
now registered with the IP address of the right hand GS-xTR's Wi-Fi
interface.

**Lin Han:** So is the IP layer that does all the work to push and
advertise the connection between GS-xTR to the satellite.

**Dino Farinacci:** No, it's in the mapping system. The EID to RLOC
mappings are in the mapping system and it does not know the type of
interface.

**Lin Han:** The satellite network does not know what is behind.

**Dino Farinacci:** Exactly.

### LISP Site External Connectivity   {#lisp-site-external-connectivity}

*   https://datatracker.ietf.org/doc/draft-jain-lisp-site-external-connectivity/
    
    10 Minutes (Cumulative Time: 45 Minutes)  
    Prakash Jain

**Dino Farinacci:** \[slide4\] Format is unchanged but what is the
reason to send a Map-Notify?

**Prakash Jain:** Because what we want to have is a dynamic adjustment
of the pETR. If there's something changed in the pETR it has to be
updated at the ITR.

**Dino Farinacci:** That functionality is documented in PubSub.

**Chairs:** Let's discuss this at the end.

**Dino Farinacci:** It's a contradiction of terms if you say you receive
the negative map reply with a locator count of non-zero.

**Prakash Jain:** I said that it is similar.

**Dino Farinacci:** What's most important is what's the action value in
that negative map reply.

**Prakash Jain:** We can call it like a regular map reply with the EID
prefix similar to the EID prefix of the negative reply. But it is not
communicating any action value just the ETR information.

**Prakash Jain:** Last slide question for WG adoption

**Padma Pillay-Esnault:** WHat happens in the case where you have a
negative map reply and it's going to give you a range which is larger?

**Prakash Jain:** we should not call it negative even if it looks
similar to a negative map-reply because of the EID.

**Padma Pillay-Esnault:** We need to be careful here you have the pETR
attracting the traffic of everybody else who are not yet up.

**Prakash Jain:** The purpose of this is that we wish we fall forward
but encapsulated to the border.

**Chairs:** Sorry to interrupt you. The discussion is interesting and
should continue on the mailing list so that we may reach the point of
adoption.

### Discussion Rechartering   {#discussion-rechartering}

*   15 Minutes (Cumulative Time: 60 Minutes)

**Chairs:** Postponed due to lack of time. To be continued on the
mailing list.

**Dino Farinacci:** Ask 2 hours slot for IETF 116.

**Chairs:** Noted.

### LISP PubSub Update   {#lisp-pubsub-update}

**Alberto Rodriguez-Natal:** Wanted to gather opinion about moving the
PubSub draft from experimental to Proposed Standard.

**Chairs:** Please express opinion on the mailing list.