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