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
[email protected] & [email protected]
From: Dangjuanna
Date: 2021-08-03 21:01
To: Brian E Carpenter; [email protected]
Subject: Re: [Anima] GAP Analysis and Requirements of Resource-based Network
Services Deployment
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
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
