On 10/06/2017 09:15, Carsten Bormann wrote:
> On Jun 9, 2017, at 22:43, Brian E Carpenter <[email protected]>
> 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.
>
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
