Re: [lisp] Request to LISP working group for GB-LISP ATN use cases to facilitate its adoption in ICAO.

[Dino Farinacci <[e-mail]>]

> thanks for your feedback. Please find hereafter my response.

Thanks for the response Bernhard. See responses inline.

>> 
>> Well since the subscription state is stored in the map-server for the
>> registration, when the registration goes away there will be no more Map-
>> Notifies going to the subscribers. Except for the last one when the RLOC-set
>> goes from its current state to an empty RLOC-set (since the deregistration
>> indicates to remove the entire EID entry).
>> 
>> What do you mean by your last two points "explicit selective unsubscription"
>> and "wildcard …". Are you asking what happens to these subscription types
>> when a deregitration occurs?
> 
> The request refers to an explicit unsubscribe from an EID (range of EIDs) although these EIDs are still registered. 
> E.g. if the aircraft is no longer in the responsibility of the corresponding user.

If you send a Map-Request for the EID with the subscribe bit set to 0, that clears the subscription. Was this not clear in the specifications?

> 
>>> •        Include network mobility features to draft-ietf-lisp-eid-mobility
>>> o   Add network mobility support – flag network prefixes as fixed or mobile
>> to automatic remove all longer sub-prefixes inside the mapping system
>> 
>> I know two implementations that already do this. Maybe we haven't spec'ed
>> it well, please confirm. But when a host EID is dynamically learned, the xTR
>> can be configured to register a network prefix instead of the host EID.
> 
> Aircraft have /60 IPv6 prefixes and besides these sometimes /64 sub-prefixes are registered as EIDs. 
> (This is mainly used to set different LISP priorities for certain sub-prefixes)
> If these /60 prefixes can be marked as mobile networks, then the mapping system could handle such EIDs specifically. 
> (e.g. remove all longer sub-prefixes inside the mapping system, if the corresponding connection is lost to the aircraft)

I am not sure I get the gist of the answer. Are you saying the ground-based xTRs learn the /64s of the aircraft, and when they do, you want the /60 registered? If so that is supported.

> 
> 
>>> •        Transport more information inside LISP
>>> o   4D trajectory snapshot = timestamp (in seconds) + aircraft 3D
>> coordinates
>>> o   Digital signature from the aircraft for the AGMI Request message
>>> o   “Suggest” messages on foreign report received instead of direct
>> deregistration of a foreign link -> “Solicit Deregistration”
>> 
>> Look at the functionality that draft-kowal-lisp-policy-distribution-02 is
>> spec'ing. Using JSON-formatted RLOC encodings, you can encode the
>> attributes you list above. We can do digital signatures for Map-Requests and
>> Map-Registers. Did you need it for another LISP packet type?
> 
> Thanks Dino. We will check your proposal.  
> Regarding the aircraft digital signature: This is a very domain specific functionality. We need to forward a signed message from another protocol (AGMI) via LISP to the corresponding XTRs so that they can check whether the sender of the message (AGMI message) was the aircraft.

So I have been involved in deployments, where the public-key can be registered to the mapping system and a signer of a Map-Register or Map-Request can be verified. In your case, the public-key is registered and can be looked up by your domain-specific functionality to verify whatever the domain-specific signature data runs over. See this LISP WG presentation I have given in the past on the former:

https://www.dropbox.com/s/gx5kpzaog8qgump/lisp-lisp-ecdsa-ietf-sin.pdf

> 
>> Please explain your last bullet in more detail so we can get a better
>> understanding about the functionality you are requesting.
> 
> This is also a domain specific functionality. I will try to explain it with an example: When an aircraft is connected to the ground via two different A/G links, the aircraft EID is registered by two ETRs (ETR1 and ETR2). Sometimes the aircraft detects a link failure much faster than the ground infrastructure and therefore it reports via the remaining active A/G link (to the ETR -> e.g. ETR2) that the other link is no longer available ("foreign report"). In LISP we should now have the possibility to inform (from ETR2) the corresponding ETR (where the A/G link loss occurred -> ETR1) about this link error, so that the ETR (ETR1) removes its EID/RLOC mapping after appropriate check. 

I see, you want an alternative source that detects link faster than the ETR to tell the ETR to deregister. Got it. 

Is it possible to use a restful/MIB/Yang interface to take the link down in the ETR, so the protocol and implementation will naturally deregister the EID?

Dino