Let me give some context:

1. GRASP is like all the good infrastructure pieces of an IGP,
aka: message passing including flooding across a domain.
Without being restricted to what IGPs where built for initially: unicast routes.
Hence the flexibility of GRASP. 

2. With GRASP being a new design, it's supposedly NOT ALLOWED to simply
operate as lazily insecure as pretty much all IGPs operate today. No
security at all, or a shared password known to everybody. That's
the penalty to GRASP for being late to the game. But it would also be a good
reason to consider GRASP more than than those older designs like existing IGP
for new solutions like CATS.

3.  draft-eckert-anima-acp-free-ani defines a minimum security infrastructure
    for GRASP. It's a bit of a dry read, so let me explain in simpler terms:

    - Security:
      All nodes in a network need to trust each other,
      most simply through certificates, manually installed or via BRSKI 
(RFC8995) or its variations.
    - Nodes run a GRASP Daemon. Think of it as an IGP daemon.
      GRASP daemon discovers subnet adjacent GRASP daemons via simple 
link-local multicast (DULL GRASP)
      GRASP daemons build TLS connections to those neighbors
    - GRAS daemons like IGP daemons forward/flood messages. In GRASP these are 
freely
      extensible using CBOR messages.
    - For non-flooded but unicast, GRASP just uses TLS directly between the 
nodes.

4.  draft-eckert-anima-acp-free-ani adds also functionality where 
    messages need to go through firewalls or across network edges where only
    different IP are supported on eithre side (e.g;: between IPv4, IPv6 
domains).

I haven't yet put up this draft on the top of my list, but if there is interest
now, i am happy to work on it to support efforts that would best beenfit from 
GRASP
in lightweight environments.

Cheers
    Toerless

On Thu, Mar 05, 2026 at 03:31:05PM +1300, Brian E Carpenter wrote:
> 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]

-- 
---
[email protected]

_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to