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

Lou Berger <lberger@labn.net> Sun, 27 September 2020 14:26 UTC

Return-Path: <lberger@labn.net>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9F93A0F8B for <yang-doctors@ietfa.amsl.com>; Sun, 27 Sep 2020 07:26:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.112
X-Spam-Level:
X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYrcIicy6ZAo for <yang-doctors@ietfa.amsl.com>; Sun, 27 Sep 2020 07:26:17 -0700 (PDT)
Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CAFF3A0F89 for <yang-doctors@ietf.org>; Sun, 27 Sep 2020 07:26:17 -0700 (PDT)
Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id DC64F9EE2E7CB for <yang-doctors@ietf.org>; Sun, 27 Sep 2020 08:26:15 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id MXd1kVfgMpSV4MXd1kpuxI; Sun, 27 Sep 2020 08:26:15 -0600
X-Authority-Reason: nr=8
X-Authority-Analysis: v=2.3 cv=ebkTgYMH c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=reM5J-MqmosA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=HLvPDLHGFjgA:10:nop_election2020_name_subject a=r77TgQKjGQsHNAKrUKIA:9 a=ek1ZzK3JAAAA:8 a=48vgC7mUAAAA:8 a=lXQ4aAXma2xo5KIvwZ8A:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=-RoEEKskQ1sA:10:nop_election2020_name_body a=NIOFosGgFE1dvRPHt9AA:9 a=jBo3mMT2HaanXQ07:21 a=_W_S_7VecoQA:10:nop_html a=xQ-UgBqouqXb-DtQvhst:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=eAzXvR7otJiiVf8W6HSrlbn2g1VlFxJdUuYwfUiKNHY=; b=eZf3+QHZP7bZnjad6cCqG84rmq izOHnO754Z1CZOdqnlugVuWI6G3TV0e3k4AHzH5qVgrC3hBwFXtJP7USmbnJyio0FsoeoDhWjdVES et5ZcJLd47SASQAVdHYqeA7WT;
Received: from [127.0.0.1] (port=47407 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <lberger@labn.net>) id 1kMXd1-002UUH-CP; Sun, 27 Sep 2020 08:26:15 -0600
To: Christian Hopps <chopps@chopps.org>, Martin Björklund <mbj+ietf@4668.se>
Cc: Robert Wilton <rwilton=40cisco.com@dmarc.ietf.org>, i2nsf@ietf.org, Gabriel Lopez <gabilm@um.es>, draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org, ipsec@ietf.org, last-call@ietf.org, Rafa Marin-Lopez <rafa@um.es>, yang-doctors@ietf.org
References: <MN2PR11MB4366E30B3C372D13B391AE07B53B0@MN2PR11MB4366.namprd11.prod.outlook.com> <2B88888E-A264-4D81-A8DA-9C6225E83E0E@um.es> <70A0A406-0742-4F28-A5A4-8D539B160E24@chopps.org> <20200923.125826.1562347052257995146.id@4668.se> <CBC552B2-6039-48E8-988D-4F2BA3FD6B2E@chopps.org>
From: Lou Berger <lberger@labn.net>
Message-ID: <023fc27b-f86e-ed71-0c8f-d270c338f08c@labn.net>
Date: Sun, 27 Sep 2020 10:26:11 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <CBC552B2-6039-48E8-988D-4F2BA3FD6B2E@chopps.org>
Content-Type: multipart/alternative; boundary="------------0E4061741A87736C9144E351"
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 127.0.0.1
X-Source-L: Yes
X-Exim-ID: 1kMXd1-002UUH-CP
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:47407
X-Source-Auth: lberger@labn.net
X-Email-Count: 10
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/b7vWtwJG0Jk4_94J3yNarSWWx_4>
Subject: Re: [yang-doctors] [IPsec] [Last-Call] [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Sep 2020 14:26:19 -0000

> 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+ietf@4668.se 
>> <mailto:mbj+ietf@4668.se>> wrote:
>>
>> Hi,
>>
>> Christian Hopps <chopps@chopps.org <mailto:chopps@chopps.org>> wrote:
>>>
>>>
>>>> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez <rafa@um.es 
>>>> <mailto:rafa@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-call@ietf.org <mailto:last-call@ietf.org>
>> https://www.ietf.org/mailman/listinfo/last-call
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec