Subject: [Anima] unsolicited syn messages and selective flooding in grasp

From: Liyizhou <[email-masked]>
Date: Tue, 27 Jul 2021 09:35:04 +0000

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Jul 2021 08:13:35 +1200

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

---

From: Liyizhou <[email-masked]>
Date: Wed, 28 Jul 2021 09:35:26 +0000

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-masked]] 
Sent: Wednesday, July 28, 2021 4:14 AM
To: Liyizhou <[email-masked]>; [email-masked]
Cc: Xun Xiao <[email-masked]>
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?

Regards
   Brian

On 27-Jul-21 21:35, Liyizhou wrote:
> 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 
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.
> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Jul 2021 08:52:49 +1200

On 28-Jul-21 21:35, Liyizhou wrote:
> 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
> 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.
> 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.