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.
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.
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?
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?
8. Security Considerations
We did not consider authorization of individual nodes so far in ANIMA. Does
resource management need to consider authorization?
Regards
Brian
On 08-Jul-22 18:17, internet-dra...@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
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
