Hi authors, I’ve read the recent version. This is an interesting solution. I think it should be adopted. Below are some comments.
1. The CPU_QUEUES notification value refers to the number of additional resource-specific Child SAs that may be installed for this particular TSi/TSr combination excluding the Fallback Child SA. Is it necessary to limit the amount of additional SAs at the beginning while TS_MAX_QUEUE can be used to reject the request of creating additional SA at any time? In the virtualization scenario, the new VMs can be launched on-demand, in other words, it may be seen as the number of CPUs isn’t fixed, so maybe limiting the addition SAs at the beginning will damage the flexibility. 2. The CPU_QUEUES notification payload is sent in the IKE_AUTH or CREATE_CHILD_SA Exchange indicating the negotiated Child SA is a Fallback SA. Before additional SAs are created, is there any difference between using this first/Fallback SA and using other normal SA? I think there is no difference. So maybe we don’t need to add this notification payload when creating the first SA. When the initiator wants to create an additional SA, it can directly send the request with CPU_QUEUE_INFO notification payload. There are 3 ways that the responder may reply: 1) The responder doesn’t support/recognize this notification, it will ignore this notification and reply as usual. 2) It supports this function and is willing to create the additional SA, so it will reply with CPU_QUEUE_INFO notification too. 3) It supports this function, but it isn’t willing to create more additional SAs, so it will reply with TS_MAX_QUEUE. Therefore, it seems like that CPU_QUEUE_INFO and TS_MAX_QUEUE these 2 notifications are enough to use, and the draft can be simplified to only use these 2 notifications. 3. Both peers send the preferred minimum number of additional Child SAs to install. First, I think sending the number of additional Child SAs is unnecessary. Second, when using “minimum” here my first impression is that it means 0, so in order to remove ambiguity I suggest just saying “the preferred number” (if you think sending the number is necessary). 4. If a CREATE_CHILD_SA exchange request containing both a CPU_QUEUE_INFO and a CPU_QUEUES notification is received, the responder MUST ignore the CPU_QUEUE_INFO payload. If a CREATE_CHILD_SA exchange reply is received with both CPU_QUEUE_INFO and CPU_QUEUES notifications, the initiator MUST ignore the notification that it did not send in the request. I think there is ambiguity here. When the initiator sends the CREATE_CHILD_SA exchange request containing both a CPU_QUEUE_INFO and a CPU_QUEUES notification, and the responder also adds CPU_QUEUE_INFO and CPU_QUEUES notifications in the reply, the initiator doesn’t know how to process with this situation, should the initiator ignore the CPU_QUEUE_INFO payload or notify an error to the responder? Regards & Thanks! Wei Pan (潘伟)
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
