Hi Brian, Thanks for your reply.
I am hopefully answer your questions well. > I am wondering whether we can realistically develop a generic solution for > service deployment. There can be such a variety of services. Can they really > all be described in a single framework? Is there a risk that we end up with > such a general solution that it >cannot describe the details of each service? The word "service" is generalized. I am happy to explain the service meaning in draft-dang-anima-network-service-auto-deployment. Frist of all, the networking architecture should be introduced that there is a network between the Source and Destination nodes. A service is one flow which has resource requirement. The source node generates flow that require resources; the destination node ends the related flow. Furthermore, the typical application are video services, industrial control services, and so on. The network between the source and destination nodes can provide a resource-required connection for the related flows. The establishment, update, and maintenance of this resource-based network connection for the service are the scope of resource-based network service deployment. The work involved are planning, configuration, resource-based path calculation and resource negotiation. The work of planning and resource calculation algorithms are not the scope of this document. The goal of this document is to complete the resource-based self-adaptation among service and network nodes via GRASP. For example, the network can create connections according to the service resource requirements, and the service can also adjust its own resource requirements adaptively according to the resource conditions of the network connection. Why use a distributed mechanism instead of a centralized one? I have explained in above email. >Let me ask a question: how would this proposal support a service for >assignment of IP prefixes to customer edge devices? Is it a better or worse >solution for that requirement than RFC8992? The prerequisite for the automatic deployment of resource-based network services is that the basic network has been working. The address planning and allocation of the basic network deployment should use RFC8992 with purpose of obtaining IP addresses for network nodes. After IGP is enabled, the basic network will be connected. So, the content of my document does not conflict with this RFC8992. > Also, there may be some overlap with the proposals in > draft-eckert-anima-services-dns-autoconfig. That is aimed towards > interworking with older mechanisms. I realise that draft-eckert is aimed at > network infrastructure services, but its data structures are quite general. As I know, draft-eckert-anima-services-dns-autoconfig defines standards for the auto-configuration of crucial Network Operations Center (NOC) services on ACP nodes via GRASP. In the configuration process, a method similar to draft-eckert-anima-services-dns-autoconfig should be used. For example, Should a certain network element undertake the NOC function to complete the automatic configuration of resource-based connections? I am looking forward to your reply. Best wishes, Joanna -----Original Message----- From: Anima [mailto:[email protected]] On Behalf Of Brian E Carpenter Sent: 2021年8月3日 10:36 To: [email protected] Subject: Re: [Anima] GAP Analysis and Requirements of Resource-based Network Services Deployment I am wondering whether we can realistically develop a generic solution for service deployment. There can be such a variety of services. Can they really all be described in a single framework? Is there a risk that we end up with such a general solution that it cannot describe the details of each service? Let me ask a question: how would this proposal support a service for assignment of IP prefixes to customer edge devices? Is it a better or worse solution for that requirement than RFC8992? Also, there may be some overlap with the proposals in draft-eckert-anima-services-dns-autoconfig. That is aimed towards interworking with older mechanisms. I realise that draft-eckert is aimed at network infrastructure services, but its data structures are quite general. Regards Brian Carpenter On 30-Jul-21 16:18, Dangjuanna wrote: > Hi, > > > > In the previous mailing list, our discussion in the mailing list basically > focused on the definition of GRASP. The related draft is listed in > https://datatracker.ietf.org/doc/draft-dang-anima-network-service-auto-deployment/ > > <https://datatracker.ietf.org/doc/draft-dang-anima-network-service-auto-deployment/>. > > > > In fact, the GAP analysis and requirements of Resource-based Network Services > Deployment are the most important work at present. > > > > With the development of a large number of IoT terminal accesses and > the industrial Internet accesses, the services requirement on network resources are becoming more and more demanding. The operator's network has made great efforts in this regard by adopting traffic engineering and the network calculus embedded in controller. But in fact, resource-based service deployment is an E2E concept. > > > > The actual network deployment still has the following problems. > > 1. In the campus network, not all devices might be managed by > the controller, for example, some sensors have limited computing and storage resources and cannot consume too heavy mechanisms. Or devices of different vendors might not communicate with one controller for various reasons. At this time, a distributed mechanism is needed to transfer related resource information. > > 2. RSVP is a very good resource reservation protocol, but it is coupled > with MPLS. Moreover, the protocol has no way to deal with other resource > information (such as the delay information). Also, is the RSVP too heavy in > the campus network or the end user? > > 3. Compared with the operator's network, the campus network has more > uneven resources. Actually, some nodes may have resource guarantee > requirements, such as wireless connections. > > 4. The end user and network lack of the resource-based self-adapting mechanism. > > 5. … ( Welcome to enrich / optimize / modify them ) > > 6. … > > > > For the above reasons, I have started to write this draft and try to > use GRASP to solve parts of the above problems. This draft is now in its > rudimentary form and rough, and it might not fully express my thoughts. So I > specially write this email. > > > > I strongly hope to listen your opinions, and am looking forward to your > reply. > > > > Best wishes, > > Joanna > > > > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
