Re: [lisp] Review of the LISP-NEXGON draft

Dino Farinacci <farinacci@gmail.com> Tue, 02 August 2022 20:16 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 93E1EC157B5C for <lisp@ietfa.amsl.com>; Tue, 2 Aug 2022 13:16:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0mnAyPJVwqt for <lisp@ietfa.amsl.com>; Tue, 2 Aug 2022 13:16:10 -0700 (PDT)
Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64BCC157B35 for <lisp@ietf.org>; Tue, 2 Aug 2022 13:16:10 -0700 (PDT)
Received: by mail-qv1-xf30.google.com with SMTP id i4so11509976qvv.7 for <lisp@ietf.org>; Tue, 02 Aug 2022 13:16:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc; bh=hmvL9e9dIQT9ONFPBlC1NXmEDDMdcbT4Po3NtKk33SY=; b=QNdWf9T6VAcjz2SLFQpbtfYv3b1gE9inhPVNrdYNBdM49HL4sZLKPkGMciPiJDR8bi zzA4B+Ls8gtJX60Ce8Ypy8teMR98aQugKjZwTz0QievvY6SULcuQc2KuaaRLBs/ktX6K U0q35dUbnjXZUEJUb1J689qgAHUYkztkXVlgp+5bmgRUnagXVw51EM2sUdMka3d+WAuk ybo5ln7u05NN0Uo1I7qQl2/MEp4RJGFJrsl5WjFCGoazPa2QMn2HxYvwN3KR93zDf/fU 6+pyiin/P0Gu+102y5xelc6O/O7s2VfJi3VjwqVW9cM+JW8Sb9FlGNNzmqIlBAiv/eg6 bmEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc; bh=hmvL9e9dIQT9ONFPBlC1NXmEDDMdcbT4Po3NtKk33SY=; b=NW6hopsT7sGKdJGYCjrzwItFFxTQqavPqCmAukRVCzAWL3ZfzE0l4r9LCB2rwgs5Ep W3AtbClCWAB+ZMyspmnAkFf5rjlWLLjpVHEE6xmV3sjzzGscnAmHljPoYdAuQIH24h6N FR9mTTW0ga/FCgaSiHETlO71l6KX92DvjuNYty8atNMoDGxUeOh81ZcutHOehGvrTJ1z jrORA5TWEIPlaI5yclEL5yd09qQ3uFprDFioxtsVeKV3z20SJ6KE0BQ91pFERiCVdRff eRz/eENqHlmcseoZQekefpEbFjZTdt8ktrrMiAL7p9aRMwYKgnenFm60qgbdTQZt9zST K1GA==
X-Gm-Message-State: ACgBeo0ydr7krLZD61Z7+xFWphigaGmmfasaJ7iVZHPFTrn/86ZjzqGI VnaaNO07hOYwGEZWUeeX8ts4HlMFSII=
X-Google-Smtp-Source: AA6agR7XREjM4xBouJ9V5RecBEOQR2qOulHqamIHd0VVXbu7fI/iqWJQ7kYmPokC+WBBHIDpfWtdYA==
X-Received: by 2002:a05:6214:76a:b0:476:f3d6:8eaa with SMTP id f10-20020a056214076a00b00476f3d68eaamr2518458qvz.8.1659471369905; Tue, 02 Aug 2022 13:16:09 -0700 (PDT)
Received: from smtpclient.apple ([2600:381:1026:7906:fc2a:550b:791a:24e1]) by smtp.gmail.com with ESMTPSA id de33-20020a05620a372100b006b8b3f2772bsm3820083qkb.44.2022.08.02.13.16.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Aug 2022 13:16:09 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <CAOZy3yH7yKGJparQUsA=g41ncn9W2-5XR+mW+ZyJbTQST-Rysw@mail.gmail.com>
Date: Tue, 2 Aug 2022 16:16:08 -0400
Cc: "lisp@ietf.org list" <lisp@ietf.org>, Fisher Yu <i@yf.io>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F95CCB25-7E92-4FE9-9599-503302D6CCE7@gmail.com>
References: <CAOZy3yH7yKGJparQUsA=g41ncn9W2-5XR+mW+ZyJbTQST-Rysw@mail.gmail.com>
To: Trevor Darrell <trevor@eecs.berkeley.edu>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/o_LphrVNEQs8MM63_MV--vvgwfU>
Subject: Re: [lisp] Review of the LISP-NEXGON draft
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 02 Aug 2022 20:16:14 -0000

Dear Professors Darrell and Yu,


> Professors Darrell and Yu are leading researchers in AI, Computer Vision, and Autonomous Driving, and have pioneered open-source frameworks and datasets for autonomous driving research.  Darrell has been in the field for over three decades, founded the UC Berkeley BAIR and BDD centers, and is the second most highly cited scholar in autonomous driving and the ninth-most in computer vision according to Google Scholar. Yu is a leading researcher of his generation in the area of perception for autonomous vehicles and was recently hired as a tenure-track Assistant Professor at ETH after completing a Postdoc at UC Berkeley, where he led the development of deep learning models for autonomous driving and oversaw the collection of the BDD100K dataset, which has been widely adopted in industry and academia.

We are honored you have put effort into making LISP better for your use-case. We really appreciate the feedback.

> The draft describes network aggregation of detections made by vehicles with AI cameras driving at speeds of between 0 to 50 meters per second. Detections are marked, enumerated, and localized by the vehicle, and are snapped to a geospatial grid tile based on the vehicle position and geo-perspective calculation. The enumeration and localization specified by the draft are feasible with a reasonable onboard vehicle computer and are consistent with current research results from our labs at UC Berkeley and ETH Zurich. 

That is good to know.

> Detections from each area are aggregated in algorithmically (location) addressable shards.
> 
> A consolidation process is applied to merge multiple detections from multiple points of view, varying time-stamps, and varying detection and localization errors. The consolidation process emerges the current state - enumeration of the condition of each grid tile aggregated by the shard. Both condition enumeration, data-clustering, and consolidation processing applied on network edge computers are aligned with BDD research.

One question, what if two detections, roughly at the same time, report different visualizations? Is there a policy, such that if one detected nothing and another detected an object, that you err on choosing there was an object present?

> The formal geospatial grid used for localization and consolidated aggregation is the H3geo.org hierarchical hexagonal grid, as it provides for clear tile adjacency of the grid in each resolution level. This is a useful quality in calculating perspective, propagating impact of conditions, and resolving shard border-line detections.  We believe these design decisions are reasonable.

Yes, Sharon presented this to the WG many times. We were convinced.  ;-)

> We understood the detection aggregation network is based on IETF LISP RFCs to provide:
> 
> (1) seamless (to vehicles) edge compute expansion-contraction of per street activity

Yes, the mapping system can map from an EID that describes different resolutions.

> (2) geo privacy,  preventing unwarranted vehicle tracking by geolocation services

Yes, again, the mapping system provides this service. It is centralized for management and also distributed for scale.

> (3) seamless context switching crossing shards while driving, without DNS disruption  

Yes, we call that EID-mobility.

> (4) service and subscription continuity when switching carriers/wlan while driving

Yes, the mapping system was extended from initial design to provide a PubSub capability and we are now using it for many of the use-case designs.

> (5) mobile queuing, and metro ethernet edge route coalescing: M Mbps X Few 100GE

Right, EIDs can be aggregated when they are encoded as a power-of-2 address.

> (6) replication of push notifications, network join: Vehicles X Situations X Locations

Yes, PubSub.

> Therefore we believe that LISP@IETF.org is the appropriate review venue for this draft.  Please do not hesitate to contact us for further discussion of this important topic.

That is great news. We will make sure we contact you if we need any questions answered about the use-case. But Sharon is very fluent with the use-case so he answers most of our questions.

Cheers and thanks again,
Dino