Re: [Anima] ACP [was I-D Action: draft-ietf-anima-grasp-13.txt - SONN]

[Brian E Carpenter <[e-mail]>]

On 10/06/2017 09:15, Carsten Bormann wrote:
> On Jun 9, 2017, at 22:43, Brian E Carpenter <[e-mail]> wrote:
>>
>> But if not, *somebody* is going to replicate the packets. If the VRF
>> doesn't do it, GRASP itself will have to do it. That doesn't seem optimal
>> to me.
> 
> I wonder why you are saying this.
> 
> Generally, where information needs to be disseminated to a group, there is an end-to-end argument giving the application a big role in that.  Supporting this directly in the network can only really be motivated by performance considerations(*); do you think this function here is performance-critical?

Well, we are talking about encryption here, so there is a run-time cost
that we can never optimise if it's an upper layer that replicates the
packets. However, my main concern is that the GRASP code will have to
track each neighbour relationship as a distinct virtual interface with
its own interface index, and in particular the discovery relaying code
will have to track each one separately. That is stateful, because
discovery responses have to be matched to the discovery request.
And it goes like N(neighbours).

If the VRF simply emulates multicast sending, that is a trvial
stateless process, and the GRASP state goes like N(interfaces).

Either will work, but as far as I can see having the VRF handle
LL multicast is much, much simpler. To be clear, it doesn't have
to do any multicast routing; that's why GRASP does its own
relaying. The VRF has to do something like

if message.destination_address == ALL_GRASP_NEIGHBORS_6:
    for i in neighbors:
        secure_send(message, i)

and then it can forget about it, because it's UDP.

   Brian

> 
> Grüße, Carsten
> 
> (*) or where the topology defines the group, but I don’t think this is the case here.
> 
>