Harmonization of Edge Entitys among EdgeCloud APIS for future merge

[sergiofranciscoortiz]

As discussed in Item 1 from CAMARA EdgeCloud meeting 12th December Minutes, the idea to go for a first version that includes LCM and Discovery intents is to merge current SED API with proposed MVP API in #154.

Also there are similar concepts in Traffic Influence to be taken into account.

For that we need to harmonize the naming of the entities refering to the same concepts, currently there are this entities/definitions:

API	Item	Method	Description
Simple Edge Discovery	MECPlatform	GET mec-platforms	On receiving this request, the network will return the name of the MEC platform with the shortest network path to the end user device identified in the request.
MVP EdgeCloud	EdgeCloudNode	GET edge-cloud-nodes	List of the operator’s Edge Clouds and their status, ordering the results by location and filtering by status (active/inactive/unknown)
Traffic Influence	Telco Edge Site		Edge datacentres of Telco Operator

The two methods are compatible in the sense that offer different outcomes ( SED an optimal node/platform to connect for given parameters and MVP a whole list with node/platform information). But we should harmonize the naming of the entitis MECPlatform and EdgeCloudNode ( or other) as they are referring really to the same concept.

Our proposal is trying to avoid telco acronyms in methods as suggested in CAMARA guidelines 2.5 Reduce telco specific terminology in api definitions, as MEC could be confusing ( Multiaccess, Mobile).

Following GSMA documentation we propose the term EdgeCloudNode which seems clearer than other options ( like Cloudlet) or MEC, but this is open to discussion, anyhow we should used the same naming in existing APIs.

[ThomasEdgeXR]

As discussed in the call this should be combined with finalizing the aligned terminologies https://github.com/camaraproject/EdgeCloud/blob/main/documentation/SupportingDocuments/edge_terminology.md to make sure we have a 100% aligned understanding of terminologies and their semantics in order to provide proper documentation to developers eventually.

[Kevsy]

@ThomasEdgeXR ^ agreed, as I see that both Edge Cloud and MEC Platform appear in the Terminology.

[gunjald]

To me “edgeCloudNode” with a change to "edgeCloud" seems to be the first preference among “edgeCloudNode”, “Telco edge cloud” and “MECPlatforms”. My thought process is that the telco edge cloud and MEC Platforms terms are either looking too telco centric or providing a feel of a platform for which there is no definition available neither any capability set defined and they could create a confusion. The edgeCloudName which could have been a reference to an actual edge cloud and seems neutral and very abstract to indicate compute resources. In that case it also provide more flexibility for future to refer it even non-telco scenarios. So a suggestion would be to use "edgeCloud" as including "Node" keyword in the name may be interpreted like a server or single host verbatim which is not the case.

[Kevsy]

@gunjald as discussed in the call "edgeCloud" sounds like the collection of edge sites, rather than an individual site (which is what 'Mec platform', and 'edgeCloudNode' represent.). I agree the use 'Node' is ambiguous and hence not suitable.

Suggestions to consider:

• EdgeCloud as the collection of EdgeCloudSites
• EdgeCloud as the collection of EdgeCloudLocations

...but, note 'Edge Cloud' is not provider specific in the Linux Foundation Open Edge glossary, it rather refers to the overall Edge Cloud continuum.

The Linux Foundation Open Edge glossary also defines the 'Service Provider Edge' and 'RegionalEdge' for consideration:

"
Service Provider Edge
One of the two main edge tiers in the LF Edge taxonomy, used to specify edge computing capability deployed on the service provider side of the last mile network. The Service Provider Edge consists of IT equipment placed adjacent to or in support of service provider networks in a metropolitan region and encompasses the physical geography between the access networks and the nearest internet exchange (IX) points. The Service Provider Edge further subdivides into the Access Edge and Regional Edge and is typically capable of delivering edge computing with sub-100ms latencies. Formerly referred to as the Infrastructure Edge."

"
Regional Edge
A subcategory of the Service Provider Edge consisting of server-class infrastructure located in regional data centers which also tend to serve as major peering sites. Regional edge sites are commonly in the form of Multi-Tenant Colocation (MTCO) facilities owned by companies like Equinix and Digital Realty, but can also take the form of a backhaul facility owned by a telco network that has been upgraded to house server-class IT equipment. Regional Edge sites usually provide, also, a regional Internet Exchange (IX) point, where tenants can connect to other networks and reach nationwide Internet backbones. Large cloud providers, web-scale companies, CDNs and other enterprises place servers and storage in these facilities to reduce the latency and network hops that would otherwise be required to reach a centralized data center, but which do not require the ultra low-latencies available at the Access Edge or at the User Edge. A rich confluence of data passes through these locations. Edge computing resources in a regional data center can work in conjunction with resources at the Access Edge and the User Edge to deliver different tiers of latency. As a general rule, Regional Edge data centers are capable of supporting edge workloads that can tolerate latencies in the 30ms - 100ms range.
"

...but again, there does not appear to be a clear taxonomy of collection of items in these definitions (i.e. the collections of all the individual MEC Platforms/Edge Cloud Sites (etc.) for a given operator).

[sergiofranciscoortiz]

Thanks for the suggestions @Kevsy

We find that EdgeCloudSite could be a good option:

1. We could keep EdgeCloud with the definition from linux foundation, where it is clear that it would refer to several different data centers.
2. We avoid the term Node, that indeed as stated during the call might be confusing for some interpreting it a single server. Site does not seem ambiguous at all.
3. We avoid the term MEC that might be too telco oriented.

If others agree we could update the current definition of Edge Cloud in https://github.com/camaraproject/EdgeCloud/blob/main/documentation/SupportingDocuments/edge_terminology.md reusing the definition in linux foundation glosary through a PR and also include a definition for EdgeCloudSite.

[Kevsy]

Thanks @sergiofranciscoortiz that's a good analysis.

@gunjald @ThomasEdgeXR and all - any opinion on EdgeCloudSite ?

[gunjald]

Thanks @sergiofranciscoortiz that's a good analysis.

@gunjald @ThomasEdgeXR and all - any opinion on EdgeCloudSite ?

To me both EdgeCloud and EdgeCloudSite looks very close. The word "Site" provide a notion of something like a physical site somewhere while I assume what we wanted to say is "availability of resources that can serve users at some locations like city or region etc while resources may not be in same location". Is that the correct interpretation?

[Kevsy]

To me both EdgeCloud and EdgeCloudSite looks very close. The word "Site" provide a notion of something like a physical site somewhere

Fair point about site having a physical meaning, which may lead to ambiguity.

while I assume what we wanted to say is "availability of resources that can serve users at some locations like city or region etc while resources may not be in same location". Is that the correct interpretation?

I'm not sure, because that definition could also apply to public cloud (if I am in a city or region, I can still access public cloud).

To me what we are trying to describe is a collection of resources hosted at a physical location which reduces propagation delay to certain end users. In some (not all) cases this will be those users attached to access points physically near that location.

This is what e.g. AWS call a 'local zone' , GCP call a 'Distributed Edge Zone' and Microsoft call 'Azure Stack Edge Zone'. 'Zone' seems to be the common term, and does not have the ambiguity of 'site', and is a familiar term to non-telco developers who use public clouds.

EdgeCloudZone could therefore be a suitable term. What do you all think?

[gunjald]

To your comment "To me what we are trying to describe is a collection of resources hosted at a physical location which reduces propagation delay to certain end users. In some (not all) cases this will be those users attached to access points physically near that location."

Conceptually I think the physical site or location is something that operator knows by way of the infra planning and logical network configurations e.g. high speed fiber connectivity or direct cloud interconnects etc that users from which locations will get benefit if they access applications from that edge. Purely from the API consumer perspective the real location of edge may not matter till they get the committed or offered QoS. And also an operator may not also want to reveal the physical location users and which provides a flexibility to make any future changes to resources including physical location change of the resources but keeping the same characteristics.
So from my perspective using a neutral name like EdgeCloudZone looks good as it is agnostic to physical location and still keeping the edge as keyword pointing to key capability being offered.

[ThomasEdgeXR]

I generally agree "EdgeCloudZone" may be a good term however i think it is important to be very clear what is the semantics of it, specifically can an "EdgeCloudZone" consist of one or potentially multiple "EdgeCloudSites"?
In my understanding the term "zone" in public cloud (while not strictly defined and used with different nuances by the hyperscalers) is a logical construct defining a pool of resources under a common and consistent regime, i.e. with defined characteristics. Now the key characteristic of edge resources is its location (or the result thereof, i.e. a specific, "short" path in terms of network topology from a specific client device). Thus having different "EdgeCloudSites" (i.e. different physical locations) within a zone would break that logic as each site would have a different path length. Therefore it should follow that an EdgeCloudZone can only consist of a single physical location unless there is a definition of that "path length" which would result into ranges rather than absolute values (so that different sites could fall into one of those ranges).
To make sure there is no ambiguity in going forward i would propose that in addition to the terminology definitions we create an entity-relationship-diagram (or something adequate) defining this relationships.

[Kevsy]

Thanks both - I propose EdgeCloudZone as a single 'location' that an API consumer would choose to use because it brings propagation delay reduction to end users near (on the shortest path to) that location.

E.g. in UK Vodafone has two such zones, Manchester and London. They also have more official AWS names:

London: eu-west-2-wl1-lon-wlz-1
Manchester: eu-west-2-wl1-man-wlz-1

(note these are actually Wavelength Zones, not localzones as I said earlier. But still 'zones' :))

So for terminology, an EdgeCloudZone is something like:

"A platform in the operator network, offering network, compute and storage resources to developers. A developer can deploy and run applications on an EdgeCloudZone, meaning reduced latency to end users that are nearby, as the network path is shorter. A network operator's EdgeCloud may comprise multiple EdgeCloudZones, each in a discrete location to bring latency benefits to end users across a country . The operator can help developers know which of the EdgeCloudZones will bring the best performance benefit for a given end user and application."

WDYT?

[FabrizioMoggio]

I'm mostly fine with the proposal, even if it is quite strange to have a term (EdgeCloudZone) defined as it were a variable. Why not Edge Cloud Zone for the text? As an example, in the TI API description we currently have:

The reference scenario foresees a Service, composed by one or more Service Producers deployed in different geographical locations on Telco Edge Sites (Edge datacentres of Telco Operator) or in Cloud. The Service Producer, deployed at the Edge, is referred as Edge Application Server (EAS).

I would prefer to modify it as:

The reference scenario foresees a Service, composed by one or more Service Producers deployed in different geographical locations on Edge Cloud Zones (Edge datacentres of Telco Operator) or in Cloud. The Service Producer, deployed at the Edge, is referred as Edge Application Server (EAS).

rather than:

The reference scenario foresees a Service, composed by one or more Service Producers deployed in different geographical locations on EdgeCloudZones (Edge datacentres of Telco Operator) or in Cloud. The Service Producer, deployed at the Edge, is referred as Edge Application Server (EAS).

[sergiofranciscoortiz]

Poll #197 is now closed, in the end all those who voted opted for term EdgeCloudZone, so we should be generating PRs to include that terminology in current APIs:

• Simple Edge Discovery substitute in code references to MECPlatform for EdgeCloudZone

• EdgeCloud_LcM substitute in code references to EdgeCloudNode for EdgeCloudZone

• TraffIc Influence, adapt documentation to substitute reference to Telco Edge Sites for Edge Cloud Zone, I think that your suggestion @FabrizioMoggio for the text is ok to use "Edge Cloud Zone" rather than "EdgeCloudZone"

[Kevsy]

Thanks @sergiofranciscoortiz

Changes to be made:

Schema objects:
MECPlatforms to change to EdgeCloudZones
MECPlatform to change to EdgeCloudZone

Path URIs:
mec-platforms to change to edge-cloud-zones

Documentation
"MEC Platform(s)" to change to "Edge Cloud Zone(s)"

[FabrizioMoggio]

PR #167 , introduces Edge Cloud Zones in the TI API.

[javierlozallu]

I think this discussion is resolved, can we close it @FabrizioMoggio?

[FabrizioMoggio]

yes, we can