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

Dino Farinacci <farinacci@gmail.com> Fri, 25 March 2022 19:34 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5663A0125 for <lisp@ietfa.amsl.com>; Fri, 25 Mar 2022 12:34:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhTv-WU4ZVue for <lisp@ietfa.amsl.com>; Fri, 25 Mar 2022 12:34:37 -0700 (PDT)
Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F623A00E5 for <lisp@ietf.org>; Fri, 25 Mar 2022 12:34:37 -0700 (PDT)
Received: by mail-pj1-x1034.google.com with SMTP id bx5so8358855pjb.3 for <lisp@ietf.org>; Fri, 25 Mar 2022 12:34:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ml01QtbjOxm2pnXxrtHuqBpcChjwiml8b3Fbu68Zezc=; b=F/+Olfh6tEjXM9Gqa2IFImerpH/NKFgP3RkJqoBOpm2YiWRDOQqVRlFCM8oqnArzfH 4Hev3DbNV0MJOqIj6Q5VFOtWPHvNtiQwt5qRWuwIek7R0vN57pUz3WnCMJy1xUtiM3xH KCdsA9oax8tuMN0g4bYjVuj8KhFgYMjQDVA6mGUeLtoEChuSWyU0UQTUkskyiJ+97aBp pkIDGNlpKkFmypx9YpN7IfmWlKmHq+Pydz+KcZdQSyFWUk9KNT7xi9XfNYaU8OaQ7cL9 KexvR/4z305FqZdNDc20YlpbPfi9PLR6dGhhIL7cRsS0Qkp9i0vl2ASzN3nDeJ4IqEMg k8YQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ml01QtbjOxm2pnXxrtHuqBpcChjwiml8b3Fbu68Zezc=; b=j+h/GnABsdaYdIIvrv3YORStETwyOnZX5qROtPzzIDSBBweVfkg2jfC//JehXGPI8g xTOJdmK3l0S0BDDiTnSmxqLiZJATyMF/vrkZt0YCCIZ3J/egZzc7ojh/uscXBC1YLveA kvBuqBdxqnFOSyTtVM6Vacu9YCjwQZWdNfS5piG2fwQTfCEPBuzUVsDKdKg7ULzoVFhL 5+YmQKPkjk+BjEu68KUJKK1eyPE6zjZmvHUwpkIZQ394ahM/4by4Exd3Mhkc1rnBmzIH /PAxRy853MmeC+ez2deEE5OzqdEI5UiPl+vzvY45N4Ow+ZQwquuFicdsH0N+y02x6nl8 AyPg==
X-Gm-Message-State: AOAM531JRosUqWlFbA1dYRD4Zy3vFM85N6oMT/VhJO8oF9RQy9QAiAqR rGaYh1/DUjdHx8boXrznqMc=
X-Google-Smtp-Source: ABdhPJw1Sdr0mFloAfiy5MJG9AZ3QzQehXFXtR8yEzyrVVGKkooPaNSuN9aXaSgAQLzad81zXY8pkQ==
X-Received: by 2002:a17:902:9346:b0:14f:2b9c:ad2f with SMTP id g6-20020a170902934600b0014f2b9cad2fmr13265465plp.174.1648236875746; Fri, 25 Mar 2022 12:34:35 -0700 (PDT)
Received: from smtpclient.apple (c-98-234-33-188.hsd1.ca.comcast.net. [98.234.33.188]) by smtp.gmail.com with ESMTPSA id oc10-20020a17090b1c0a00b001c7510ed0c8sm14465790pjb.49.2022.03.25.12.34.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Mar 2022 12:34:35 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <AS4PR01MB91814DD1C86353D50E598E2F891A9@AS4PR01MB9181.eurprd01.prod.exchangelabs.com>
Date: Fri, 25 Mar 2022 12:34:33 -0700
Cc: "lisp@ietf.org" <lisp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A9A345B8-83A6-416D-987A-A3CA00A05839@gmail.com>
References: <AS4PR01MB91814DD1C86353D50E598E2F891A9@AS4PR01MB9181.eurprd01.prod.exchangelabs.com>
To: HAINDL Bernhard <Bernhard.HAINDL@frequentis.com>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/KI7KvPy6bM-h1OSdCQP-CP9u9Yo>
Subject: Re: [lisp] Request to LISP working group for GB-LISP ATN use cases to facilitate its adoption in ICAO.
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Mar 2022 19:34:40 -0000

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

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.

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

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

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

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

Please explain your last bullet in more detail so we can get a better understanding about the functionality you are requesting.

Thanks for sending this email,
Dino