Re: [IPsec] [Last-Call] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

> 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 <[email protected] 
>> <mailto:[email protected]>> wrote:
>>
>> Hi,
>>
>> Christian Hopps <[email protected] <mailto:[email protected]>> wrote:
>>>
>>>
>>>> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez <[email protected] 
>>>> <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/last-call
>
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf