Hi, On Monday, March 7th, 2022 at 12:14, Antoine FRESSANCOURT antoine.fressanco...@huawei.com wrote:
> 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). That is also my reading. > 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. Different sections of the draft claim different things; some claim EIDs never change, others talk about multiple EIDs used in different scenarios. I find section 5.1 interesting: "It is anticipated that these EIDs will change infrequently if at all, since the assignment of a LISP-MN's EID is envisioned to be a subscription time event." Subscription is an undefined term that also appears in LISP+ALT. In the context of drones (not to bombard you with terminology from that area), one could imagine that subscription occurs when loading a mission plan onto a drone prior to departure. But by definition, this then only entails anticipated scenarios, not emergency response situations. A completely static drone identifier is one thing; EIDs changing rarely is another. Drones may require communications with isolated, private networks, which are outside the scope of LISP+ALT - how subscription should be interpreted here is an interesting topic! > 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. Also my understanding. > 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). I fear that view is somewhat incomplete, though not from a 3GPP perspective. EASA (at least) regulation require multiple distinct radio technologies for fail over of command & control (C2) links. One way of viewing this is to treat the C2 link as an abstract interface that is dynamically mapped to one of several radios; this multi-link (somewhat distinct from multi-homed, but very similar) approach is currently gaining in popularity, it seems. That in turn implies that a SIM-based identifier at best identifies the link used, not the vehicle itself. While it is technologically feasible to use the SIM ID in other links and vice versa a WiFi MAC address in 3GPP networks, neither would be their intended purpose. It is also possible to punt drone identification entirely to a layer above (which is the approach we're currently taking), but that just means we're also implicitly accepting a drone identifier<->link identifier (/ EID) mapping as an additional level of indirection. In other words, none of this currently covers the kind of identification needs this space has. (There is an aside here I'll spare you on how these identifiers most likely need to be (hashes of) public keys.) For what it's worth, I am well aware that it's entirely fair to treat these kinds of identifiers as an application layer concern. On the other hand, the applications are almost exclusively concerned with addressing at this level of abstraction. At that moment one has to ask what purpose an EID serves here, unless it is as static as and therefore equivalent to the drone identifier? I'm not sure if this is the right list to discuss this, though; this is, after all, affecting mostly LISP-MN/LISP+ALT. The general RFC 6115 distinction between identifiers and locators still makes sense, it's more how LISP-MN may or may not interpret identifiers that raises some questions for me. But I suppose that's relevant enough? Hope that helps, Jens
publickey - jens@interpeer.io - 0x5C345E9C.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
