On 28-Jul-21 21:35, Liyizhou wrote:
> Hi Brian,
>
> Can't remote ASA being discovered with a specific objective during discovery
> process indicate it wants the unsolicited-sync of this objective value to be
> sent from a local node?
>
> That's my assumption of how unsolicited_synch-message defined in section 5.1
> in draft-ietf-anima-grasp-distribution to be used no matter it uses
the same message type as (M_ SYNCH) or not.
Certainly the exact message format is a detail; it might re-use M_SYNCH or it
might not. That isn't the difficulty. Pub/sub is a different model from either
flood (which is a pure push model) or synchronize (which is a request-response
model). Pub/sub requires quite complex state at the publisher (a list of all
individual destinations that require updates of which objectives) and extra
state at the subscriber (a list of all individual
ASAs that require updates of which objectives). It's a lot more complicated to
design and implement than either flooding or synchronization.
(I don't think the model in draft-ietf-anima-grasp-distribution is anything
like complete yet. I certainly haven't worked out whether it can actually be
implemented yet.)
Regards
Brian
>
>
> Rgds,
> Yizhou
>
>
> -----Original Message-----
> From: Brian E Carpenter [mailto:[email protected]]
> Sent: Wednesday, July 28, 2021 4:14 AM
> To: Liyizhou <[email protected]>; [email protected]
> Cc: Xun Xiao <[email protected]>
> Subject: Re: unsolicited syn messages and selective flooding in grasp
>
> Hi Yizhou,
>
> GRASP synchronization is a request/response protocol, so with no request,
> there can be no response.
>
> How does the ASA that sends an unsolicited M_SYNCH know where to send it, and
> how would the remote ASA tell GRASP that it wanted the result?
>
> The answer is that it's impossible, so you need to develop a pub/sub
> solution, which is actually more complicated, so there is a separate draft.
There is no real cost in adding a new message type. That is not the complicated
part of pub/sub.
>
> Regards
> Brian
>
> On 27-Jul-21 21:35, Liyizhou wrote:
>> Hi,
>>
>>
>>
>> When reading RFC8990 and draft-ietf-anima-grasp-distribution, I found
>> RFC8990 allows Flood Synchronization Message (section 2.8.11) to be
>> **unsolicited** but Synchronization Message does not allow so. I guess
>> that’s why unsolicited_synch-message is defined in section 5.1 in
>> draft-ietf-anima-grasp-distribution.
>>
>>
>>
>> So why not simply allow the synch-message (M_SYNCH) to be sent
>> unsolicitedly instead of define a new message type? It looks like more
straight forward.
>>
>> BTW section 5.1 in draft-ietf-anima-grasp-distribution is quite
>> different from the rest subsections as it defines a new message type
>> and the rest are for objectives. Some re-structure of the subsection
>> titles may make
> it more self-descriptive.
>>
>>
>>
>> I am trying to figure out what would be the best messages to be used
>> to
> distribute mapping info from IP address/prefix to access control group IDs as
> suggested in draft-yizhou-anima-ip-to-access-control-groups. Both the
> Objective providers (i.e. access authentication point, AAP in this case) and
> Objective consumers (i.e. policy enforcement point, PEP in this case) are
> supporting the same ASA/Objective. However, it would be ideal when the Syn
> message is flooded unsolicitedly, the message is only moving towards the
> Objective consumers but not the other Objective providers. I had thought the
> selective flooding can be leveraged here. However current selective flooding
> seems not quite for this purpose. Consider the following topology, if I
> understand it correctly, when the selective flood flows
from node1 to node 2 and then node 3, it would stop at node 2 if the matching
condition fails at node 2. Then even node 3 meets the matching rules, the
message would not reach it.
>>
>>
>>
>> Node 1 (ASA 1) --- Node 2(ASA 2)---Node 3(ASA1)
>>
>>
>>
>> Come back to the IP prefix to group id mapping information distribute
>> case, there might be nodes not supporting this specific ASA/objective
>> in between of the objective providers and consumers. It would be
>> expected that the message can pass through such intermediate nodes.
>> Certainly, multiple unicast syn messages can be used since the nodes
>> supporting this objective would have been discovered at the discovery
>> stage. I am wondering if
> flooding like approach is also a good option here.
>>
>>
>>
>> Thanks,
>>
>> Yizhou
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
