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 <[email protected]>
Date: July 20 2022 13:34
To: [email protected]
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, [email protected] 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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
