[icnrg] New Version Notification for draft-li-icnrg-damc-02.txt

[Xueting Li <[e-mail]>]

Dear all,

A new version of Internet-Draft draft-li-icnrg-damc-02.txt has been
successfully submitted by Xueting Li and posted to the
IETF repository.
 
Name:     draft-li-icnrg-damc
Revision: 02
Title:    Distributed architecture for microservices communication based on Information-Centric Networking (ICN)
Date:     2023-10-18
Group:    Individual Submission
Pages:    20
URL:      https://www.ietf.org/archive/id/draft-li-icnrg-damc-02.txt
Status:   https://datatracker.ietf.org/doc/draft-li-icnrg-damc/
HTMLized: https://datatracker.ietf.org/doc/html/draft-li-icnrg-damc
Diff:     https://author-tools.ietf.org/iddiff?url2=draft-li-icnrg-damc-02
 
Abstract:
 
   This draft defines a new communication architecture, called
   Distributed Architecture for Microservices Communication (DAMC).  It
   includes multiple aspects of microservice communication, such as
   service registration, service discovery, service routing, service
   scheduling, and more , Which to achieve all the essential
   functionalities provided by current centralized service networks.
   The purpose of this draft is to combine the Information-Centric
   Networking (ICN) concept to enhance the overall performance,
   scalability and reliability of microservices communication.  The DAMC
   architecture provides a powerful framework for managing the complex
   communication requirements of distributed microservices, ensuring
   integrity, security and efficient resource utilization.

Summary of the changes made in this version compared to the previous versions:
Introduction
Based on valuable advice from David R. Oran, we have made modifications in the introduction section to provide 
a more accurate citation of references and adjusted relevant content to better reflect our architectural design principles and objectives.

Terminology
In the terminology section, we have also provided explanations for the terms used in the document to enhance clarity.
Key process / distributed service mesh architecture

We have made some wording adjustments. For instance, we replaced "owned" with "service located" to align with the concept of sharing network namespaces and storage in a "Pod." Regarding the complexity of prefix identity authentication, we have opted not to delve into detailed explanations in this document, as we plan to offer comprehensive insights in subsequent files to ensure a thorough understanding. 

The term "topology link information" refers to the foundational data that contributes to the subsequent creation of the Link State Database. This essential information is broadcast through the interfaces of the Service Gateway. It encompasses the internal topology of pods, the topology between various Service Gateways and pods, and the topology information among pods, Service Gateways, and Service Routers (to be elaborated).

The computation of the Forwarding Information Base (FIB) is a collaborative effort involving both the Service Gateway and the Service Router. In this context, we plan to leverage existing routing protocols for computation, such as ISIS. Detailed documentation regarding this aspect is currently under development. 

The term "detection" in this context refers to the process of ensuring the quality and reliability of communication between microservices. To achieve this, the Service Gateway needs to assess the health status and availability of each target microservice. In essence, this "detection" mechanism allows the Service Gateway to monitor and ensure the overall robustness and seamless operation of communication between microservices. A more precise term would be "service availability monitoring".

This monitoring of health status encompasses, but is not limited to, the following aspects:
Service Liveliness: Verifying if the target microservice is operational and capable of processing requests.
Resource Utilization: Monitoring the resource usage of microservices to ensure there is no resource depletion or excessive utilization.
Latency and Response Time: Measuring microservices' response time and latency to ensure there is no significant performance degradation during communication.
Error Rate: Detecting the error rate of microservices, including request failure rates, abnormal responses, etc., in order to make timely adjustments or take necessary actions.

The Service Gateway gathers this information through regular monitoring mechanisms. This data is then utilized to dynamically distribute traffic and make routing decisions based on the health of microservices. This contributes to a stable service communication environment, ensuring high availability and performance.
Key communication message types & functions
In our document, different messages may correspond to different protocols. We plan to continue using existing mature protocols, and specific details will be provided in subsequent documents.

Regarding failure detection, communication, and recovery mechanisms for various components, these critical aspects are part of our ongoing development. We are actively working to define robust processes that ensure timely detection of failures, seamless communication of these events to relevant components, and effective recovery strategies.

As for the instantiation of the initial state defining the structure of a DAMC (Distributed Application Microservices Communication) instance, this is another area of our ongoing refinement. We are carefully considering how to establish the foundational configuration that governs the DAMC instance, incorporating best practices and well-defined procedures.

Regarding service measurement: In our document, service measurement is implemented as follows:

Service Gateway: The Service Gateway assumes the role of traffic proxy within the service-oriented network. Positioned at the forefront of service communication, it not only forwards and processes traffic but also collects data pertaining to communication between services. This encompasses crucial metrics such as traffic data, latency, error rates, and other key indicators.

Service Mesh Communication Scheduling Center: Within the service-oriented network, the Service Mesh Communication Scheduling Center component operates in a manner akin to Istio's Telemetry function. Its responsibility lies in gathering, processing, and storing data generated by the Service Gateway. This data includes access logs, metrics, and information necessary for distributed tracing.

Operation process…
We have made adjustments to the wording in this section, such as changing 'Podcast' to 'Pod' . The relevant content has also been modified, and specific details can be found in the draft.

The above serves as a summary of the modifications made in this version. The primary focus of this draft is to introduce our overall architecture. Further refinements of certain theoretical details will be provided in subsequent drafts, and we will offer targeted explanations of key processes in separate drafts. 

If you have any comments or suggestions, please feel free to reach out to us. Your feedback is highly appreciated.


Best regards,
Xueting Li


The IETF Secretariat                                                        


Xueting Li
China Telecom
[e-mail]