Re: [Int-area] Continuing the addressing discussion: what is an address anyway?

Antoine FRESSANCOURT <antoine.fressancourt@huawei.com> Mon, 07 March 2022 11:15 UTC

Return-Path: <antoine.fressancourt@huawei.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACB33A0897 for <int-area@ietfa.amsl.com>; Mon, 7 Mar 2022 03:15:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 b5PTqKack2iT for <int-area@ietfa.amsl.com>; Mon, 7 Mar 2022 03:14:59 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64663A07F7 for <Int-area@ietf.org>; Mon, 7 Mar 2022 03:14:56 -0800 (PST)
Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KBwn601V9z67tWW; Mon, 7 Mar 2022 19:13:30 +0800 (CST)
Received: from lhreml728-chm.china.huawei.com (10.201.108.79) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 7 Mar 2022 12:14:53 +0100
Received: from lhreml726-chm.china.huawei.com (10.201.108.77) by lhreml728-chm.china.huawei.com (10.201.108.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 7 Mar 2022 11:14:53 +0000
Received: from lhreml726-chm.china.huawei.com ([10.201.108.77]) by lhreml726-chm.china.huawei.com ([10.201.108.77]) with mapi id 15.01.2308.021; Mon, 7 Mar 2022 11:14:53 +0000
From: Antoine FRESSANCOURT <antoine.fressancourt@huawei.com>
To: Jens Finkhaeuser <jens@interpeer.io>, Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: Toerless Eckert <tte@cs.fau.de>, "Int-area@ietf.org" <Int-area@ietf.org>, Dirk Trossen <dirk.trossen=40huawei.com@dmarc.ietf.org>
Thread-Topic: [Int-area] Continuing the addressing discussion: what is an address anyway?
Thread-Index: AdgRu64YB5eA1MJiQEiPQSsbU7BQswAA/ICABvLpPoAABrn7gABImqoAABbfaYAAJh6fAAARYhYAAIBWYAAAA+TlsA==
Date: Mon, 07 Mar 2022 11:14:53 +0000
Message-ID: <d128f1fc15824cae9012ab5f30358221@huawei.com>
References: <57c643c667d94a77b9917bb17dc142a5@huawei.com> <7de0956f-3fde-1543-405b-b635f6e69362@lear.ch> <Yh5M18z2/YVfpW7i@faui48e.informatik.uni-erlangen.de> <A771FFF8-43A8-4D84-8B6E-A3E7AF96644E@gmail.com> <YiBhOKIK9bMqwx0a@faui48e.informatik.uni-erlangen.de> <385CF477-C876-482F-ADFE-DAAD6CA7BAEC@gmail.com> <YiH6iHwv+U9QFA06@faui48e.informatik.uni-erlangen.de> <499a3364-7ea5-4268-cce3-43f010f36a72@gmail.com> <Gpm-qFUmOVey9DYUJV6S_UNYb02p7ANbT8rEjy8JA54B__1YeX6Uny2E16uEg_o-R7v9CWPdDbyOgNW7nJyACAbx7Ok99Q-zad1EsgYBerc=@interpeer.io>
In-Reply-To: <Gpm-qFUmOVey9DYUJV6S_UNYb02p7ANbT8rEjy8JA54B__1YeX6Uny2E16uEg_o-R7v9CWPdDbyOgNW7nJyACAbx7Ok99Q-zad1EsgYBerc=@interpeer.io>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.201.117.184]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/kjSkcc7IFEr_wdCyyN7XzZ1ydSQ>
Subject: Re: [Int-area] Continuing the addressing discussion: what is an address anyway?
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area WG Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Mar 2022 11:15:17 -0000

Hello,

Reading the ISP-MN draft, it seems to me that EIDs are identifiers, not locators, even if they take the form of IPvX addresses (By the way, this is a perfect example of the Locator - identifier ambiguity of IP, highlighted in Mobile IP discussions). The text of the draft mentions that they change infrequently and besides they are irrelevant from a topological perspective with regards to where the drone is roaming. The RLOC is an address, and I think it has relevance from a topological perspective if it can be used to point to the antenna / access point to which the drone is attached.

If I make a comparison with what is happening in 3GPP mobile networks, the ID of the device (drone, sensor, mobile phone, laptop, you name it) is carried by the SIM and appears as an IMSI to the outside (bearing in mind that in theory, the IMSI is a public ID, and a device can have several public IDs attached to the private one carried in the SIM's secure element). This IMSI is used in attachment procedure to get a data channel and an IPvX address that is relevant to the visited network in which the device is roaming / attached. Within this scoep of relevance, the device is supposed to be reachable by means of ARP-like discovery mechanisms (well, it uses a specific network function coupled with a database to perform the discovery, but the goal is the same).

Best regards,

Antoine

-----Original Message-----
From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Jens Finkhaeuser
Sent: Monday, March 7, 2022 10:12 AM
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Toerless Eckert <tte@cs.fau.de>; Int-area@ietf.org; Dirk Trossen <dirk.trossen=40huawei.com@dmarc.ietf.org>
Subject: Re: [Int-area] Continuing the addressing discussion: what is an address anyway?

Hi,

I'm new on the list - I'll just jump in, I suppose. I'm working on a couple of R&D projects on drone communications, where most participants tend to invent a different wheel from people here. Part of my being here is trying to bridge that gap a bit.

I largely like the RFC 6115 definition, as it is also compatible with the URI/URL definitions more people might be used to. That should help with adoption.

I've been reading up on LISP-MN and/or LISP+ALT (that's on a different list, I know), and am currently unsure that these proposals fully meet the needs of drones. I'll have to understand the proposals better.

The addressing related point here is IMHO the RFC 6115 definition for identifiers may be more suitable for drone uses than the LISP-MN proposal treats EIDs: drones must carry static identifiers for authentication of control handover, while the EID assignment in the proposal reads to me as slightly more dynamic (though not as dynamic as RLOC assignment).

Hope that helps,
Jens

------- Original Message -------

On Friday, March 4th, 2022 at 20:57, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

> Toerless,
> 

> I believe the closest we ever got to agreed definitions was in the
> 

> IRTF RFC 6115:
> 

> 6. A "locator" is a structured topology-dependent name that is not
> 

> used for node identification and is not a path. Two related
> 

> meanings are current, depending on the class of things being
> 

> named:
> 

> 1. The topology-dependent name of a node's interface.
> 

> 2. The topology-dependent name of a single subnetwork OR
> 

> topology-dependent name of a group of related subnetworks
> 

> that share a single aggregate. An IP routing prefix is a
> 

> current example of the latter.
> 

> 7. An "identifier" is a topology-independent name for a logical
> 

> node. Depending upon instantiation, a "logical node" might be a
> 

> single physical device, a cluster of devices acting as a single
> 

> node, or a single virtual partition of a single physical device.
> 

> An OSI End System Identifier (ESID) is an example of an
> 

> identifier. A Fully Qualified Domain Name (FQDN) that precisely
> 

> names one logical node is another example. (Note well that not
> 

> all FQDNs meet this definition.)
> 

> Regards
> 

> Brian
> 

> On 05-Mar-22 00:39, Toerless Eckert wrote:
> 

> > On Thu, Mar 03, 2022 at 09:28:23AM -0800, Dino Farinacci wrote:
> > 

> > > > of its address structure helps the underlay to locate the entity (xTR) that the
> > > > 

> > > > address is assigned to (xTR). So the name 'locator' is 'just' a good
> > > > 

> > > > name for what LISP calls/uses the address for, not for how the under
> > > > 

> > > > itself would maybe call the address or use the address for.
> > > 

> > > Well the locator you put in an outer header destination address is called/used/assign to whatever the rules of the underlay are. If the underlay is ethernet, then its a 6-byte address where the high-order 3 bytes is an organizational ID, just to cite an example.
> > 

> > Indeed.
> > 

> > I have not seen an answer to the question i posed earlier in the thread:
> > 

> > whether and if so what general (not technology specific) definition of locator
> > 

> > and identifier the IETF may have. But i have seen a lot of confusion about
> > 

> > it and people shying away from using these terms.
> > 

> > If (as i think) we do not have a commonly applicable definition of locator/identifier
> > 

> > (beyond its use in indivdual technologies like LISP), then i think this is because
> > 

> > folks who tried to apply these terms (incorrectly) may have failed to
> > 

> > see the difference between what an address is and what someone (like an
> > 

> > application) calls it (/uses it for). In that respect the reference to
> > 

> > the White Knight in IEN19 is very helpful to remember.
> > 

> > Cheers
> > 

> > Toerless
> > 

> > > Dino
> 

> _______________________________________________
> 

> Int-area mailing list
> 

> Int-area@ietf.org
> 

> https://www.ietf.org/mailman/listinfo/int-area