Hi all,
We've updated a draft of use cases and requirements of STANDALONE Service ID in
routing network after the IETF 118 presentation of service ID for addressing
and networking. The update is trying to scroll back from the preliminary
solution to focus upon the use cases and requirements. The use cases have been
categorized into two general scenarios:
A. South-North scenario. The service traffic is transmitted between the
terminals at the user side and the servers at the cloud sites for which the
same service could be deployed at multiple sites as well as over heterogeneous
resources, namely location and resource independent. Furthermore, the ongoing
interface mechanisms between service and network are overwhelmingly complicated
and un-scalable.
B. East-West scenario. The service traffic is transmitted betweeen the services
and cloud sites for which the interconnection between the services has to go
through multiple L4/L7 gateways and semantics mapping and translation, thus the
delay and registry complexity incurred would be untolerable for the
transmission performance sensitive services.
In a nutshell, the authors believes it's quite necessary from perspectives of
both performance and intelligence of the network to employ a standalone service
ID in routing network with the following features:
A general, simple and unified service ID for multiple routing area scenarios in
which the service ID needs to be location and resource independent for the
corresponding frameworks and an simplified interface is indespensible between
application-level services and network.
A general exposure interface of the underlay networking and computing
capabilities to the third parties.
A general identification with only the service semantics which would be user
independent.
As for the the term "Service ID" for which no one in the author would insist,
it would better be a brainchild of the community.
We are scheduling a side meeting at IETF 119 in Brisbane, anybody would be
welcome to reach the co-authors and me with any comments, suggestions.
The agenda is pending, so presentations about use cases, requirements, problems
and solutions would be appreciated. The agenda capacity for presention slots
would be about 5, so I will encourage the application be confirmed by the
first week of March.
Best regards,
Daniel Huang
ps: the draft link:
Name: draft-huang-rtgwg-us-standalone-sidRevision: 00Title: Use
Cases-Standalone Service ID in Routing NetworkDate: 2024-01-29Group:
Individual SubmissionPages: 17URL:
https://www.ietf.org/archive/id/draft-huang-rtgwg-us-standalone-sid-00.txtStatus:
https://datatracker.ietf.org/doc/draft-huang-rtgwg-us-standalone-sid/HTML:
https://www.ietf.org/archive/id/draft-huang-rtgwg-us-standalone-sid-00.htmlHTMLized:
https://datatracker.ietf.org/doc/html/draft-huang-rtgwg-us-standalone-sid
黄光平 huangguangping
标准团队/有线规划部 Wireline architecture team./Wireline Product R&D Institute
南京市雨花区软件大道50号中兴通讯2号楼
R&D Building, ZTE
Corporation Software Road No.50,
Yuhua District, Nanjing, P..R.China, 210012
M: +86 13770311052
E: [email protected]
www.zte.com.cn
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
