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. 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
