Subject: [Anima] How GRASP could manage GRASP

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Aug 2021 17:17:16 +1200

Hi,

Following up on my previous message, here are some thoughts about how GRASP could manage itself. It will be a lame autonomic protocol if it can't manage itself ;-).

One mechanism is that a "GRASP manager" ASA in an autonomic node associated with the NOC could send out configuration messages as GRASP floods. In all other autonomic nodes, a local "GRASP manager" ASA could receive these floods and act accordingly. 

For example, we could build this capability on top of what is already proposed in draft-eckert-anima-grasp-dnssd. Something like:

   objective-value  /= { 1*elements }
   elements        //= ( @rfcXXXX: { 1*relement } )

   relement  = ( relement-codepoint => relement-value )
   relement-codepoint = uint
   relement-value     = any

   ...

   relement-codepoint //= ( &(grasp-control:3) => grasp-config )

   grasp-config  =  {
        ?( &(grasp-version:1)  => 0..255),
        ?( &(max-flood:2)      => 0..65536),
        ?( &(max-unicast:3)    => 0..65536),
       }

This allows us to specify a GRASP version for the domain (RFC8990 is version 1, of course) and maximum message sizes for flooding and unicast. This would be easily extensible for any other aspects of GRASP that we want to configure within a domain.

(It's clear that we might also want to add an authentication/authorization mechanism to such messages, because they could be very dangerous if misused.)

Is this idea worth following up?

Regards
   Brian

P.S. Thanks to Michael Richardson, Toerless Eckert and Carsten Bormann for some early discussion.

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 24 Aug 2021 08:45:01 +0000

Hi, Brian,

I am fully support that there should be a mechanism to config GRASP in the certain domain and also the flood methods. However, I have no clean the definition of grasp-version and why. Are we going to have multiple GRASP versions active in the same time? For my understanding, in an any giving time, we should have one fully version of GRASP, then we may have many subsets of this full version of GRASP, which may be combinations of functionalities/options of GRASP for different scenarios. Now, the question would be whether we, as ANIMA WG, should define these subsets as standard with a registered number then easier to flood it in the operation or leave them as individual functions/options but "GRASP manager" can announce their availability on each function/option base.

Regards,

Sheng

> -----Original Message-----
> From: Anima <[email-masked]> On Behalf Of Brian E Carpenter
> Sent: Saturday, August 21, 2021 1:17 PM
> To: Anima WG <[email-masked]>
> Subject: [Anima] How GRASP could manage GRASP
> 
> Hi,
> 
> Following up on my previous message, here are some thoughts about how
> GRASP could manage itself. It will be a lame autonomic protocol if it can't manage
> itself ;-).
> 
> One mechanism is that a "GRASP manager" ASA in an autonomic node associated
> with the NOC could send out configuration messages as GRASP floods. In all
> other autonomic nodes, a local "GRASP manager" ASA could receive these floods
> and act accordingly.
> 
> For example, we could build this capability on top of what is already proposed in
> draft-eckert-anima-grasp-dnssd. Something like:
> 
> This allows us to specify a GRASP version for the domain (RFC8990 is version 1, of
> course) and maximum message sizes for flooding and unicast. This would be
> easily extensible for any other aspects of GRASP that we want to configure
> within a domain.
> 
> (It's clear that we might also want to add an authentication/authorization
> mechanism to such messages, because they could be very dangerous if
> misused.)
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Aug 2021 08:58:24 +1200

Hi Sheng,

On 24-Aug-21 20:45, Sheng Jiang wrote:
> Hi, Brian,
> 
> I am fully support that there should be a mechanism to config GRASP in the certain domain and also the flood methods. However, I have no clean the definition of grasp-version and why. 

I agree. This was intended as an example rather than a definite proposal.

> Are we going to have multiple GRASP versions active in the same time? 

If (and only if) we added a version concept to GRASP, I suppose this could happen in a large network, with some nodes updated.

> For my understanding, in an any giving time, we should have one fully version of GRASP, then we may have many subsets of this full version of GRASP, which may be combinations of functionalities/options of GRASP for different scenarios.

Or, perhaps, a new function (e.g. as suggested by draft-ietf-anima-grasp-distribution) would be supported in some networks but not in others.

> Now, the question would be whether we, as ANIMA WG, should define these subsets as standard with a registered number then easier to flood it in the operation or leave them as individual functions/options but "GRASP manager" can announce their availability on each function/option base.

Exactly right. So the first question for the WG is: do we need such a capability?

(At the moment, all we have to support subsets or unkown extensions is the M_INVALID message, so that one node can tell another "I didn't understand that".)

Regards
   Brian