This is a sub-optimal compromise b/c all IPsec have SA databases even
ones running IKE -- i.e., SA databases are common whether exposed in
YANG or not -- but if it can move it forward perhaps good enough.
Speaking as an interested party, I hope that some compromise / good
enough solution is followed in the -09 version of this draft.
Lou
On 9/23/2020 7:20 AM, Christian Hopps wrote:
On Sep 23, 2020, at 6:58 AM, Martin Björklund <mbj+i...@4668.se
<mailto:mbj+i...@4668.se>> wrote:
Hi,
Christian Hopps <cho...@chopps.org <mailto:cho...@chopps.org>> wrote:
On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez <r...@um.es
<mailto:r...@um.es>> wrote:
But I would like to check: My understanding is that the changes that
Chris is proposing are pretty small. I.e. move the SA structure under
ipsec-common, and put it under a YANG feature. Are you sure that it
is impractical to accommodate this change which would allow a single
ipsec module to be shared and extended via YANG augmentations?
In the context of our I-D, if we move SAD structure to ipsec-common,
what we are meaning is that IPsec SA configuration data (setting
values to the SAD structure) are common to the IKE case and the
IKE-less cases, which are not. It is confusing.
Something defined in a common module but marked as a feature does not
imply that that feature has to be implemented by an importing
module. This is not confusing to YANG implementers or users I
think. If we are just talking about document flow here, then a
sentence saying "the SAD feature is not required to implement IKE
functionality" is quite enough to clear that up I think.
Another alternative could be to move these containers to another
(new) module.
It may also be enough to mark the notifications in the ikeless module
as a feature I suppose. That is the actual thing I think non-SDN
implementations would want to omit. The module name "ikeless" is not
great in this case, but perhaps workable.
This is a sub-optimal compromise b/c all IPsec have SA databases even
ones running IKE -- i.e., SA databases are common whether exposed in
YANG or not -- but if it can move it forward perhaps good enough.
I'm definitely concerned about IETF process and real world usability
here. These modules are basically workable for ipsec I think, they
could be used by operators today. If we restart the entire process to
redo this work for the more generic IPsec case it will probably be
years before they are finished and in the field. This new work can be
started, but why not have something usable in the meantime?
Thanks,
Chris.
/martin
Thanks,
Chris.
Moreover, the usage of feature means that, after all, this “common” is
not “common” to both cases IKE case and IKE-less. Again, it seems
confusing. In the IKE case, the SDN/I2NSF controller does not
configure the SAD at all but the IKE implementation in the NSF. In our
opinion, in order to properly add this IPsec SA operational state to
the IKE case we should include operational data about the IPsec SAs
(config false) to the ietf-ipsec-ike. Alternatively, we have certain
operational data (ro) in the SAD structure in the IKE-less case. If
only those are moved to the common part should be ok but we think it
does not solve the problem.
--
last-call mailing list
last-c...@ietf.org <mailto:last-c...@ietf.org>
https://www.ietf.org/mailman/listinfo/last-call
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
