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
