Re: [Anima] I-D Action: draft-ietf-anima-network-service-auto-deployment-02.txt

Hi Brain,

	I am very grateful to get your comments about my draft. Some of my thoughts are marked below in the form of [Yujing]. I am very welcome to discuss them in the meeting at IETF 114.

	Regards
	Yujing

--------------------------------
From: Brian E Carpenter <brian.e.carpenter@gmail.com> 
Date: July 20 2022 13:34
To: anima@ietf.org
Subject: Re: [Anima] I-D Action: draft-ietf-anima-network-service-auto-deployment-02.txt

By the way, the draft I mentioned below, draft-ietf-core-yang-cbor, is now RFC9254!

This should make it rather easy to include YANG in GRASP objective values.

Regards
    Brian

On 18-Jul-22 15:59, Brian E Carpenter wrote:
> Hi,
> 
> I have a few questions and comments on this draft. Please consider them at the same time as any discussion in the meeting at IETF 114.
> 
>>   1. Introduction
> ...
>>  From the network perspective, this kind of service has a source IP address and a destination IP address.
> 
> Are these always unicast addresses? Are there any cases in which one of the addresses might change (e.g. a node moves from a wired connection to WiFi, or moves from one WiFi subnet to another)?
> 
> Also, do you consider the case where a node fails and must be replaced automatically by another?
> 
> Perhaps my real question is this: Does the model cover *renegotiation* when the resource status changes unexpectedly?
> 
> I think your answer is yes, but that makes the statement about "a source address" and "a destination address" questionable, if both addresses might change.

[Yujing] The current discussion scope of this draft is limited to unicast addresses. I think if the resource status changes unexpectedly, the end side will receive a large number of replies of message transmission failure, or some existing measures can make the end side aware of the address changes of the sender and receiver of the message. In this case, the end side will re negotiate the reservation of resources and can follow the section 6.4 to change resource requirements.

>>   5. Autonomic Resource Management Objectives
> ...
>> objective-value = n-s-deployment-value ; An n-s-deployment-value is defined as Figure-2.
>>
>>   n-s-deployment-value
>>       + service-information
>>           + source-ip-address
>>           + destination-ip-address
>>           + service-tag
>>       + resource-information
>>           + resource-requirement-pair
>>               + resource-type
>>               + resource-value
>>
>> Figure-2: Format of n-s-deployment-value
> 
> I don't understand Figure 2. It looks like YANG rather than CDDL. There is an approved draft on YANG to CBOR in the RFC Editor queue (draft-ietf-core-yang-cbor).  It's presumably OK to specify a GRASP objective value in YANG, with the mapping to CBOR defined by draft-ietf-core-yang-cbor, but if that is the plan, please state it precisely in the draft, with the necessary references.

[Yujing] I'm very grateful for your suggestions. And I'll read RFC9222 carefully. Figure 2 I want to express the hierarchy and inclusion relationship between fields, but my expression may be nonstandard. I will fix it according your suggestions.

>>   6.3. An example of multiple domain network
> 
> It may be useful to mention that this situation (an ASA facing two different domains) is described in the Security Considerations of RFC9222 as a possible loophole. What rules are necessary to prevent any unwanted actions across the domain boundary?

[Yujing] I agree with you that this situation is a possible loophole and it is necessary to establish some rules to restrict across the domain boundary actions. In this draft, only some special nodes, like ASBR PRM ASA, can obtain information in another domain. These special nodes can communicate with other domain nodes under certain restrictions, but direct operations on other domain nodes should be avoided. However, I think this is a common problem, and I hope to have a separate draft to discuss it or scholars of security can put forward some suggestions.

>>   7. Compatibility with Other Technologies
> 
> I think this section needs to discuss DetNet. I do not follow the work in DetNet but they must be discussing resource allocation. Could ANIMA be the correct solution for DetNet?

[Yujing] I agree with you. This draft wants to use the ANIMA negotiation process to decide how much resources the domain can offer to service. This mechanism supports the negotiation of resources such as queues reserved for DetNet resources, and can be considered as a distributed solution of DetNet resource demand negotiation.

>>   8. Security Considerations
> 
> We did not consider authorization of individual nodes so far in ANIMA. Does resource management need to consider authorization?

[Yujing] This draft does not want to introduce additional problems for ANIMA and security is not the focus of this draft. This draft hopes to complete the autonomic mechanism for resource-based network services deployment in the domain under the condition of complying with the security measures of ANIMA.

> Regards
>       Brian
> 
> On 08-Jul-22 18:17, internet-drafts@ietf.org wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF.
>>
>>           Title           : An Autonomic Mechanism for Resource-based Network Services Auto-deployment
>>           Authors         : Joanna Dang
>>                             Sheng Jiang
>>                             Zongpeng Du
>>                             Yujing
>>     Filename        : draft-ietf-anima-network-service-auto-deployment-02.txt
>>     Pages           : 14
>>     Date            : 2022-07-07
>>
>> Abstract:
>>      This document specifies an autonomic mechanism for resource-based
>>      network services deployment through the Autonomic Control Plane (ACP)
>>      in a network.  This mechanism uses the GeneRic Autonomic Signaling
>>      Protocol (GRASP) in [RFC8990] to exchange the information among the
>>      autonomic nodes so that the resource along the service path can be
>>      coordinated.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-anima-network-service-auto-deployment/
>>
>> There is also an htmlized version available at:
>> https://datatracker.ietf.org/doc/html/draft-ietf-anima-network-service-auto-deployment-02
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-network-service-auto-deployment-02
>>
>>
>> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>>
>>
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima