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 protected]> On Behalf Of Brian E Carpenter > Sent: Saturday, August 21, 2021 1:17 PM > To: Anima WG <[email protected]> > 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: > > 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. > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
