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
