Paul Wouters writes:
> On Mon, 20 Nov 2023, Tero Kivinen wrote:
>
> > After some probing in the Prague, we managed to get good discussion
> > and reviews on this draft, and I think the consensus on the list was
> > that it should be ready to go forward.
>
> Note that we are still discussing on th
On Mon, 20 Nov 2023, Tero Kivinen wrote:
After some probing in the Prague, we managed to get good discussion
and reviews on this draft, and I think the consensus on the list was
that it should be ready to go forward.
Note that we are still discussing on the list with Valery on a few
items, so
After some probing in the Prague, we managed to get good discussion
and reviews on this draft, and I think the consensus on the list was
that it should be ready to go forward.
The adoption calls are still waiting for our security AD to respond,
but I will start the ones listed on our charter when
Hi Paul,
I snipped parts where we are in agreement.
> > 2. Section 2
> >
> > There are a number of practical reasons why most Implementations have
> > to limit a Child SA to only one specific hardware resource, but a key
> > limitation is that sharing the crypto state, counters and sequence
On Tue, 14 Nov 2023, Valery Smyslov wrote:
I support publication of this draft. I'm glad authors took my points into
consideration
while preparing the latest version. I do have some comments though.
1. Section 1
IKEv2 [RFC7296] already allows installing
multiple Child SAs with identical T
On Wed, 15 Nov 2023, Yoav Nir wrote:
Do you think it be better for each end to announce a maximum ahead of time?
(At negotiation of the first child SA)
I think so, but not completely sure.
Suppose one peer is willing to go to 32 parallel SAs, while the other is going
to stop at 8, because on
> On 14 Nov 2023, at 19:46, Michael Richardson wrote:
>
>
> Yoav Nir wrote:
>> - Although it is implied, it should be stated explicitly that
>> TS_MAX_QUEUE does not mean no more child SAs with these TS ever. As
>> some child SAs get deleted and perhaps not rekeyed if they’re idle, if
>> traf
Yoav Nir wrote:
> - Although it is implied, it should be stated explicitly that
> TS_MAX_QUEUE does not mean no more child SAs with these TS ever. As
> some child SAs get deleted and perhaps not rekeyed if they’re idle, if
> traffic picks up again, new child SAs with these TS can
Hi,
I support publication of this draft. I'm glad authors took my points into
consideration
while preparing the latest version. I do have some comments though.
1. Section 1
IKEv2 [RFC7296] already allows installing
multiple Child SAs with identical Traffic Selectors, but it offers no
m
> On 13 Nov 2023, at 12:31, Sahana Prasad wrote:
>
> Hello,
>
> I've read the draft and support its adoption.
To clarify, the draft is already adopted since July 2021. The question now is
whether it is ready to proceed to publication.
> Specifically, we (at Red Hat) have use cases where c
I support the draft to be moved forward.
some nits:
"""
2. Performance bottlenecks
There are a number of practical reasons why most Implementations have ...
"""
"""
As per RFC 7296
"""
Should we move section 8 into the appendix instead of removing the section ?
I am also interested in the
Hello,
I've read the draft and support its adoption.
Specifically, we (at Red Hat) have use cases where customer to data center
links
see performance penalties for enabling IPsec on these
connections. We've been looking at how to fix this and this draft
seems to be a solution for our use case.
T
Hi.
I’ve read the draft. Overall, it’s similar to a non-standardized solution we
did at Check Point several years ago, so I agree that it is a solution that
works. Of course, since there *are* a bunch of working implementations, that
is not particularly insightful.
With a lot of flows, it’s l
I have read the draft. I think the draft could advance as it is.
I have a few editorial comments, which authors may take with a grain of salt.
On the implementation considerations:
} This information
} MAY be used by the peer to select the most optimal target CPU to
} install the additio
I've read the draft and spent the last 2 months testing/evaluating/debugging
the linux xfrm implementation. I think the code is quite elegant and the
results are very promising (line rate on 100G ENA nic) and thus support
this draft.
There is quite a bit of interest in my company (Aviatrix Systems
Obligatory: I have read the draft.
I strongly support advancing this work to RFC status. We definitely have plans
to use this with IP-TFS development both in linux kernel as well as in other
projects such as VPP.
Thanks,
Chris.
Tero Kivinen writes:
This will start three week working grou
This will start three week working group laste call for
draft-ietf-ipsecme-multi-sa-performance. The working group last call
will end at 2023-11-15.
Please review the document and send comments to the list if you think
it is ready for publication.
--
kivi...@iki.fi
__
17 matches
Mail list logo
