Hi Jens,
I'm not sure about your requirements. I think that identifiers for AAA
can be unique and static on their "layer" and do not need to coincide
with network addresses. So if you just want to be sure that you are
talking to the right node, some UUID or public key hash should be fine
for AAA purposes.
However, if you actually want to get to a particular NodeID, no matter
where this node is currently attached to in the underlying network, then
the solution is probably related to the network layer and routing:
you need either need ID-based routing or some ID/Locator split solution
like ILNP or LISP etc. It is also a question of how "self-contained" the
solution should be: on the one hand, one can use overlay solutions for
NodeID to Locator resolution and then use the usual underlay(s) to get
to the locators. On the other hand, every overlay adds complexity,
overhead and is a potential source for inconsistencies.
So if your problem is to get control over a particular drone with a
certain NodeID, ID-based addressing is probably quite beneficial.
Regards,
Roland
On 07.03.22 at 10:12 Jens Finkhaeuser wrote:
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.carpen...@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
