Thanks, Atoine, inline
> Do IMSI have any structure ?
>
> [AFT] An IMSI is 3 digits Mobile Country Code (MCC) then 3 digits Mobile
> Network code (MNC) then 10 to 12 digits identifier.
>
> An E.164 address for example is often a hybrid, where there are country and
> even network prefixes, which like routing prefixes can be seen as locators,
> whereas the suffix is an identifier...
>
> [AFT] I would argue that this structure is more of a norm to allow the
> distributed allocation of a unique identifier than something that has a sort
> of topological relevance. For instance, if you have several national network
> to network interfaces between operators, the bridge between one mobile
> network to another can happen at any bridge, thus the MNC part of the IMSI is
> a bit more of a service address or the identifier of an identity service
> provider.
So, when i am roaming from another country, would that carrier not try to
connect to
my home carrier by the combination of MCC and MNC ?
That feature to me would make MCC+MNC similar to a routing prefix, right ?
Cheers
toerless
>
> On Mon, Mar 07, 2022 at 11:14:53AM +0000, Antoine FRESSANCOURT 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). 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-boun...@ietf.org] On Behalf Of Jens
> > Finkhaeuser
> > Sent: Monday, March 7, 2022 10:12 AM
> > To: Brian E Carpenter <brian.e.carpen...@gmail.com>
> > Cc: Toerless Eckert <t...@cs.fau.de>; Int-area@ietf.org; Dirk Trossen
> > <dirk.trossen=40huawei....@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.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
>
> --
> ---
> t...@cs.fau.de
--
---
t...@cs.fau.de
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
