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

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 12 Oct 2020 16:01:35 +0000

Hi Rafa, authors,

Just to check.

Has there been any closure on the suggestion from Chris on “notifications in the ikeless module as a feature"?  This would seem to be a fairly cheap & easy compromise.

Thanks,
Rob

From: yang-doctors <[email-masked]> On Behalf Of Lou Berger
Sent: 27 September 2020 15:26
To: Christian Hopps <[email-masked]>; Martin Björklund <[email-masked]>
Cc: Robert Wilton <rwilton=[email-masked]>; [email-masked]; Gabriel Lopez <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Rafa Marin-Lopez <[email-masked]>; [email-masked]
Subject: Re: [yang-doctors] [IPsec] [Last-Call] [I2nsf] 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-masked]<mailto:[email-masked]>> wrote:

Hi,

Christian Hopps <[email-masked]<mailto:[email-masked]>> wrote:

On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/last-call

_______________________________________________

IPsec mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/ipsec

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Mon, 12 Oct 2020 21:07:46 +0200

Hi Rob:

My apologies but I have just seen this e-mail. We were working on posting last v09 precisely today, assuming this was all clarified and the decision was to change the names as Tom suggested.

Regarding your comment, having "the notifications in the ikeless module as a feature" would not help. Let me explain. The ikeless module needs something inherent to operate, which are the notifications. It is not something optional for the ikeless module to implement.

Hope this helps.

Best Regards.

> El 12 oct 2020, a las 18:01, Rob Wilton (rwilton) <rwilton=[email-masked]> escribió:
> 
> Hi Rafa, authors,
>  
> Just to check.
>  
> On Sep 23, 2020, at 6:58 AM, Martin Björklund <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi,
> 
> Christian Hopps <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
> 
> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>_______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Christian Hopps <[email-masked]>
Date: Mon, 12 Oct 2020 16:21:51 -0400

> On Oct 12, 2020, at 3:07 PM, Rafa Marin-Lopez <[email-masked]> wrote:
> 
> Hi Rob:
> 

That does not seem like enough justification for not having the module be usable in such a broader fashion. It is obvious to anyone implementing this for your use case that the notifications must be implemented. If you feel that it is not obvious for some reason a simple sentence can make that clear. Although I would think that sentence might start with the word "Obviously, ..." :)

Thanks,
Chris.

> 
> Hope this helps.
> 
> Best Regards.
> 
>> El 12 oct 2020, a las 18:01, Rob Wilton (rwilton) <rwilton=[email-masked] <mailto:rwilton=[email-masked]>> escribió:
>> 
>> Hi Rafa, authors,
>> 
>> Just to check.
>> 
>> From: yang-doctors <[email-masked] <mailto:[email-masked]>> On Behalf Of Lou Berger
>> To: Christian Hopps <[email-masked] <mailto:[email-masked]>>; Martin Björklund <[email-masked] <mailto:[email-masked]>>
>> Cc: Robert Wilton <rwilton=[email-masked] <mailto:rwilton=[email-masked]>>; [email-masked] <mailto:[email-masked]>; Gabriel Lopez <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Rafa Marin-Lopez <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/i2nsf <https://www.ietf.org/mailman/listinfo/i2nsf>
> Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Tue, 13 Oct 2020 06:15:52 +0200

Hi Christian (, Rob):

Thanks for your comments. We really appreciate them. Please see some comments inline.

> El 12 oct 2020, a las 22:21, Christian Hopps <[email-masked]> escribió:
> 
> 
> 
>> On Oct 12, 2020, at 3:07 PM, Rafa Marin-Lopez <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Rob:
>> 

As you may remember we gave several justifications about why these changes are not correct in the context of the I2NSF work. Let me send you the link to avoid repeating myself :) 

https://mailarchive.ietf.org/arch/msg/i2nsf/IZyRrrTZu7tVm5Kpqe2mw5-kZ1w/ <https://mailarchive.ietf.org/arch/msg/i2nsf/IZyRrrTZu7tVm5Kpqe2mw5-kZ1w/> 

Thus, the change “the notifications in the ikeless module as a feature” is just the tip of the iceberg of a bigger change discussed in that link (moving SAD container to the common module). In other words, just simply adding "the notifications in the ikeless module as a feature” is not useful and does not help. In fact, the notifications must be defined in the ikeless module, and adding a feature in the ikeless module would not make any sense. 

As a consequence, the resolution was to move forward with a pragmatic approach at this point of time, by changing the names of the modules (and prefixes) to refer to the I2NSF work.

Best Regards.

---

From: Christian Hopps <[email-masked]>
Date: Tue, 13 Oct 2020 04:38:31 -0400

> On Oct 13, 2020, at 12:15 AM, Rafa Marin-Lopez <[email-masked]> wrote:
> 
> Hi Christian (, Rob):
> 
>> El 12 oct 2020, a las 22:21, Christian Hopps <[email-masked] <mailto:[email-masked]>> escribió:
>> 
>> 
>> 

These are 2 different things. The original discussion was about moving the SAD and SPD from ikeless module to the common one which then would have brought them into the IKE module, and required people just implementing IKE to also implement the SAD and SPD parts.

In comparison this new compromise request is a tiny change, and allows a much larger audience to reap the benefit of your work. The change is the addition of "feature ikeless-notification" and then putting the "if ikeless-notification" under the notifications.

This doesn't change the semantics of your module it just allows people to re-use the ikeless module for supporting SAD and SPD w/o implementing the notifications.

If you feel more clarity is needed for the SDN use-case then adding the text, "To allow for greater re-use of this module, the notifications are marked as a feature. For the SDN use case clients will expect this feature to be implemented."

Features are reported just as modules are in the capabilities. An SDN client would look for both capabilities rather than just the one (along with all the other capabilities they will be looking for to actually be a functional YANG client).

Thanks,
Chris.

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Thu, 15 Oct 2020 09:12:32 +0200

Hi Christian (,Rob):

Thanks again for this conversation. Please see our comments inline.

> If you feel more clarity is needed for the SDN use-case then adding the text, "To allow for greater re-use of this module, the notifications are marked as a feature. For the SDN use case clients will expect this feature to be implemented.”

We agree that this is a small change (if no other change is required). In fact, we have tested it and we have not observed any technical problem. The main concern is the one I mentioned to Rob: having a feature to “activate” notifications (or not) in the ikeless module does not fit in the context of this I-D, unless we find out a valid use case where this feature makes sense. 

In other words, it would be really nice if the inclusion of the text you proposed (“To allow for greater…” ) had a main text to support how this is useful in the context of this I-D. Personally, this would make me feel more confortable. 

Having said all this, let us inform about v09 changes to I2NSF wg and ask about this new change in order to see if there is any objection. Then, if there is no objection we can prepare v10 very quickly with this additional modification.

We hope this is reasonable.

Best Regards.

---

From: Christian Hopps <[email-masked]>
Date: Thu, 15 Oct 2020 06:48:26 -0400

This is great news, Thanks!

IMO (Rob feel free to chime in here :) I don't think you need to say anything more about the feature in your document (other than what was already mentioned). This is the standard "outside the scope of this document" kind of thing. It's enough to put that text that says they are marked as a feature for greater re-usability, but SDN clients will expect the feature to be implemented.

FWIW, When talking about YANG features I'd use the turn of phrase "to indicate whether notifications are implemented by the server" rather than 'to "activate" notifications'. They don't get turned on or off, they are either implemented or not. You could swap "implemented" with "supported" too here with the same meaning.

Thanks,
Chris.

> On Oct 15, 2020, at 3:12 AM, Rafa Marin-Lopez <[email-masked]> wrote:
> 
> Hi Christian (,Rob):
>