Subject: Re: [Anima] GAP Analysis and Requirements of Resource-based Network Services Deployment

From: "[email-masked]" <[email-masked]>
Date: Mon, 2 Aug 2021 18:54:51 +0800

Hi，
    
    IMO, if the user equipment can join in and support the GRASP, it would be helpful.

    The user equipment can not support RSVP, which is complex.
 
    Perhaps it can support a simpler way to communicate the resource requirements to the network, and make sure the network can fulfill its requirements.

Best Regards
Zongpeng Du

[email-masked] & [email-masked]
 
From: Dangjuanna
Date: 2021-07-30 12:18
To: [email-masked]
Subject: [Anima] GAP Analysis and Requirements of Resource-based Network Services Deployment
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/.
 
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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Aug 2021 14:35:50 +1200

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/>.
> 
>  
> 
> 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.
> 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.  
> 4.       The end user and network lack of 
the resource-based self-adapting mechanism.
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Dangjuanna <[email-masked]>
Date: Tue, 3 Aug 2021 13:01:44 +0000

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-masked]] On Behalf Of Brian E Carpenter
Sent: 2021年8月3日 10:36
To: [email-masked]
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

> 1.       In the campus network, not all devices might be managed by 
> the controller, for example, some sensors have
> 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.
> 
>  
>

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 5 Aug 2021 17:49:13 +0800

Hi Joanna,
    
        The term  Service has many meanings in the network.

        It is better to give a specific explanation in the draft, or using other terms instead.

Best Reagrds
Zongpeng Du

From: Dangjuanna
Date: 2021-08-03 21:01
To: Brian E Carpenter; [email-masked]
Subject: Re: [Anima] GAP Analysis and Requirements of Resource-based Network Services Deployment
Hi Brian,
 
Thanks for your reply.

 

 

 
Best wishes,
Joanna
 
-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: 2021年8月3日 10:36
To: [email-masked]
Subject: Re: [Anima] GAP Analysis and Requirements of Resource-based Network Services Deployment

 
 
Regards
   Brian Carpenter