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

From: HAINDL Bernhard <[email-masked]>
Date: Mon, 11 Apr 2022 07:55:24 +0000

Hi Dino,

thanks for your feedback. Please find hereafter my response.

> > After a few aisle conversations following Tuesday’s GB-LISP presentation,
> here is a revised list of asks to the LISP WG:
> 
> I was going to summarize your asks after hearing them this week. But I'm glad
> you beat me to it and refined them a bit. See comments inline.
> 
> > •        Bring RFC 6830 and RFC 6833 to Standard Track (pending since more
> than 400 days).
> 
> Yes, we are working hard on these. And now its a process issue out of the
> hands of the working group. I believe the chairs are keeping close watch on
> this.

We appreciate your support and we know that the issue is currently outside the working group.  
Therefore, there was also a corresponding e-mail from ICAO.

> 
> But I think you can count on them being standards. The question is when.
> 
> > o   The aviation community needs standards for LISP Control and Data plane
> protocols. The lack of these standards is currently a major risk for GB-LISP
> 
> Your message was clear about that and we will do whatever we can to get you
> there.

As already stated we know that and we appreciate your support!

> > •        “Publish/Subscribe Functionality for LISP” - > Move from Experimental
> to Standards Track
> 
> I support this request. I have an implemenation of the latest PubSub and put
> in specific features for the ATN use case.

Thanks Dino!

> 
> > o   More details on some pubsub operations – what happens with
> subscription after deregistration, explicit selective unsubscription, wildcard
> subscription and unsubscription
> 
> 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.

> > •        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)

> > •        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.

> 
> 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. 

> 
> Thanks for sending this email,
> Dino
> 
> 
> 
Regards
 Bernhard

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 11 Apr 2022 13:49:04 -0700

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

Thanks for the response Bernhard. See responses inline.

> 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?

> (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.

> 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 t…

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

> 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 tw…

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