Hi Brian,
Thank you very much for your detailed review and valuable comments on this
draft. We have read your feedback carefully, and your insights are extremely
helpful for us to improve the draft. Below are our initial thoughts and ideas
for improvement regarding the several issues you raised, and we look forward to
further discussion with you.
->Regarding the validity of the GRASP Objective CDDL format. You pointed out
that the validity of the GRASP Objective CDDL format has not been verified,
which is a crucial reminder. We agree that ensuring strict compliance with CDDL
is very important for clarity and interoperability. In the next version of the
draft, we will carefully check the CDDL snippets using standard tools (e.g.,
CDDL validators) to ensure they conform to RFC 8610 specifications and correct
any potential syntax issues. Thank you for highlighting this; we will address
it promptly.
->Regarding the necessity of Section 4.3.2 "GRASP Negotiation Process". You
noted that this section might be redundant, as the negotiation process for
GRASP is already fully defined in RFC 8990, and any slight discrepancies in
description could cause confusion. We completely agree with this observation.
The original intention of Section 4.3.2 was to provide readers with an
application-level overview of the negotiation process, helping them understand
how the RM ASA utilizes GRASP messages to implement intent negotiation and
deployment, rather than to replace or redefine the GRASP protocol itself.
However, we also realize that such an overview does carry the risk of
inconsistency with RFC 8990 and may seem redundant to readers familiar with
GRASP. We are inclined to simplify or delete this section. Our current thought
is to directly reference the relevant sections of RFC 8990 instead, focusing on
explaining how the basic GRASP mechanisms are invoked in the application
scenarios of this draft (e.g., joint negotiation of multiple resources). We
welcome your specific suggestions on this modification approach.
->Regarding failure handling in path negotiation and the dry-run
functionality in Section 4.4. Your suggestion to consider using GRASP's
"dry-run" functionality to optimize resource reservation and failure handling
is an excellent idea. The current draft describes a mechanism involving
temporary reservation first, followed by release and trying the next path if
negotiation fails. This mechanism could indeed increase the overhead and
complexity of resource locking. The dry-run mode, however, allows for
"simulated" negotiation before formal commitment, automatically cleaning up the
state upon failure, which aligns better with GRASP's design philosophy. We will
further investigate the dry-run mechanism in RFC 8990 and attempt to integrate
the dry-run negotiation process into Section 4.4. Our preliminary idea is that
the Service Initiator ASA could first negotiate with each Responder using
dry-run mode for tentative resource reservation and path evaluation. Only after
success would it proceed with formal negotiation to commit the final
configuration. This approach would ensure feasibility while avoiding long-term
invalid resource locking. We will evaluate the feasibility of this plan in the
revised version, describe this process in more detail, and welcome any further
specific suggestions from you on this matter.
Thank you again for your review. Your comments not only point out the
shortcomings of the current draft but also provide us with optimization
directions more closely aligned with GRASP's design principles. We truly value
this exchange with you and look forward to your continued guidance to help us
improve the draft.
Best regards,
Jialu Du
杜嘉璐
北京邮电大学/研博生/计算机学院（国家示范性软件学院）
北京
------------------ Original ------------------
From: "Brian E Carpenter"<[email protected]>;
Date: Sat, Mar 7, 2026 11:40 AM
To: "Anima WG"<[email protected]>;
"draft-du-anima-service-intent-auto-deployment"<[email protected]>;
Subject: Re: I-D Action:
draft-du-anima-service-intent-auto-deployment-00.txt
Hi,
A very short review of this draft: I like what it's trying to do, and it is a
good companion for draft-dang-anima-network-service-auto-deployment. My
impression is that the GRASP objective definitions are OK, but I haven't
verified that they are valid CDDL.
Why bother with section 4.3.2? The GRASP negotiation process is completely
defined in RFC 8990, and can be programmed quite simply if the GRASP API
[RFC8991] is available. The danger in this section is that it might be
different in some way from RFC 8990.
One specific question about section 4.4:
> If the current path negotiation fails, the Service Initiator ASA MUST
release all temporarily reserved resources and attempt the next candidate path.
Did you consider using the GRASP dry-run feature for this?
(https://www.rfc-editor.org/rfc/rfc8990.html#section-2.5.5-1)
Regards/Ngā mihi
Brian Carpenter
On 03-Mar-26 02:13, [email protected] wrote:
> Internet-Draft draft-du-anima-service-intent-auto-deployment-00.txt is now
> available.
>
> Title: The Autonomic Deployment
Mechanism of Service Intent in Autonomic Networks
> Authors: Jialu Du
>
Ye Tian
>
Xiangyang Gong
>
Sheng Jiang
> Name:
draft-du-anima-service-intent-auto-deployment-00.txt
> Pages: 18
> Dates: 2026-03-02
>
> Abstract:
>
> This document defines a generic service intent
deployment mechanism.
> It enables automated negotiation and coordination
of heterogeneous
> resources. The mechanism uses RM ASAs and
the Generic Autonomic
> Signaling Protocol (GRASP) for dynamic
interactions and resource
> exchanges. It specifies a complete workflow
covering intent
> reception, parsing, responder selection,
negotiation, solution
> integration, resource confirmation, and dynamic
adjustment. It
> employs standardized message formats, a
negotiation state machine,
> and convergence logic to jointly optimize multiple
resources and
> ensure end-to-end service level objectives.
Its design features good
> scalability and fault tolerance, making it
suitable for automated
> orchestration and lifecycle management in
intent-driven networks.
>
> The IETF datatracker status page for this Internet-Draft is:
>
https://datatracker.ietf.org/doc/draft-du-anima-service-intent-auto-deployment/
>
> There is also an HTML version available at:
>
https://www.ietf.org/archive/id/draft-du-anima-service-intent-auto-deployment-00.html
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> I-D-Announce mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
