Kehan,
But I think it doesn't necessarily depend on ACP. Can GRASP be implemented
decoupled from ACP?
Technically, yes, but GRASP has no intrinsic security. For that reason, the
GRASP standard REQUIRES a secure substrate:
https://www.rfc-editor.org/rfc/rfc8990.html#name-required-external-security-
The point is that TLS could protect most GRASP messages, but not the M_FLOOD
and M_DISCOVERY multicasts.
(In my open source implementation of GRASP I added a non-standardized
encryption mechanism. I am not recommending this, but it proves that such
security is possible:
https://datatracker.ietf.org/doc/draft-carpenter-anima-quads-grasp/ . The code
is still lurking at https://github.com/becarpenter/graspy .)
Regards/Ngā mihi
Brian Carpenter
On 05-Mar-26 14:52, Yao Kehan wrote:
Hi Michael,
Thanks for the review.
>Yes, having CATS as an ASA seems reasonable.
Will you have an ACP?
[KY] The draft follows the traditional approach for deloying ASA (Establish ACP
channel and then signaling GRASP messages).
But I think it doesn't necessarily depend on ACP. Can GRASP be implemented
decoupled from ACP? (Sorry that I have not closely followed the progress of
ANIMA.)
How big are the CATS metrics?
The B.2 use cases are generally thinking about objects in the hundreds of
kilobytes to megabytes like .. O(2^18)
I would think CATS metrics would be at the O(2^10) size?
[KY] It depends on implementation. In CATS metrics definition, there are three metric
levels. https://datatracker.ietf.org/doc/draft-ietf-cats-metric-definition/
<https://datatracker.ietf.org/doc/draft-ietf-cats-metric-definition/>
The Level 0 (raw metrics) may contain many detailed compute and service
metrics, expressed in floating points, whose size can be large.
For simplification and routing-friendly(easy to converge, small overhead),
implementers can also choose Level 1 or Level 2 normalized metrics, which can
be represented in 1 to 10 usigned integer value, whose size can be very small.
Cheers,
Kehan
----邮件原文----
发件人：Michael Richardson <[email protected]>
收件人：Yao Kehan <[email protected]>,anima <[email protected]>,"[email protected]"
<[email protected]>
抄 送: (无)
发送时间：2026-03-05 02:23:05
主题：Re: [Anima] New draft on GRASP extension for CATS metrics distribution
Yao Kehan <[email protected]> wrote:
> This document describes an approach by extending GRASP signaling
> protocol for CATS metrics distribution.
Yes, having CATS as an ASA seems reasonable.
Will you have an ACP?
> Authors think it is aligned with the use cases like V2X described in
CATS use cases and requirements:
> https://datatracker.ietf.org/doc/draft-ietf-cats-usecases-requirements/
> as well as
> https://datatracker.ietf.org/doc/draft-ietf-anima-grasp-distribution/
How big are the CATS metrics?
The B.2 use cases are generally thinking about objects in the hundreds of
kilobytes to megabytes like .. O(2^18)
I would think CATS metrics would be at the O(2^10) size?
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
Subject：Re: [Anima] New draft on GRASP extension for CATS metrics distribution
Yao Kehan <[email protected]> wrote:
> This document describes an approach by extending GRASP signaling
> protocol for CATS metrics distribution.
Yes, having CATS as an ASA seems reasonable.
Will you have an ACP?
> Authors think it is aligned with the use cases like V2X described in
CATS use cases and requirements:
> https://datatracker.ietf.org/doc/draft-ietf-cats-usecases-requirements/
> as well as
> https://datatracker.ietf.org/doc/draft-ietf-anima-grasp-distribution/
How big are the CATS metrics?
The B.2 use cases are generally thinking about objects in the hundreds of
kilobytes to megabytes like .. O(2^18)
I would think CATS metrics would be at the O(2^10) size?
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
_______________________________________________
Anima 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]
