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
>
> Regards,
>
> Sheng
>
>> -----Original Message-----
>> From: Anima <anima-boun...@ietf.org> On Behalf Of Brian E Carpenter
>> Sent: Saturday, August 21, 2021 1:17 PM
>> To: Anima WG <anima@ietf.org>
>> 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
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
