> 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
