Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-03.txt

Qin Wu <bill.wu@huawei.com> Tue, 12 September 2017 03:11 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7252413293A for <l3sm@ietfa.amsl.com>; Mon, 11 Sep 2017 20:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
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 YPpF1iBg8TON for <l3sm@ietfa.amsl.com>; Mon, 11 Sep 2017 20:11:11 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B761321A6 for <l3sm@ietf.org>; Mon, 11 Sep 2017 20:11:09 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DVG36327; Tue, 12 Sep 2017 03:11:07 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 12 Sep 2017 04:11:06 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.219]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 12 Sep 2017 11:11:02 +0800
From: Qin Wu <bill.wu@huawei.com>
To: David Ball <daviball@cisco.com>, l3sm <l3sm@ietf.org>
CC: "Benoit Claise (bclaise)" <bclaise@cisco.com>, adrian <adrian@olddog.co.uk>, "Jan Lindblad (jlindbla)" <jlindbla@cisco.com>
Thread-Topic: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-03.txt
Thread-Index: AQHTJvl1LUN8x/LDjUWvHXDkwgSGUKKnpP4ggAfVTYCAAR3wEA==
Date: Tue, 12 Sep 2017 03:11:02 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9AB0DDDD@nkgeml513-mbx.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABA9AAFC86C@nkgeml513-mbx.china.huawei.com> <b85886fa-7f8f-3e56-a8cb-7d72c4828fba@cisco.com>
In-Reply-To: <b85886fa-7f8f-3e56-a8cb-7d72c4828fba@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.79.163]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9AB0DDDDnkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.59B7504C.000B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.219, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 3559a394797ae8daebdfca3b7d662411
Archived-At: <https://mailarchive.ietf.org/arch/msg/l3sm/v9hkse0VBuK4zjgsTdxaxtsJMog>
Subject: Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-03.txt
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: L3VPN Service YANG Model discussion group <l3sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3sm>, <mailto:l3sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l3sm/>
List-Post: <mailto:l3sm@ietf.org>
List-Help: <mailto:l3sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3sm>, <mailto:l3sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Sep 2017 03:11:14 -0000

发件人: L3sm [mailto:l3sm-bounces@ietf.org] 代表 David Ball
发送时间: 2017年9月12日 1:56
收件人: Qin Wu; l3sm
抄送: Benoit Claise (bclaise); adrian
主题: Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-03.txt


Thanks Qin.

I checked and I think a few things that we agree previously haven't yet been incorporated:

  *   In Sn 6.12.3.2, regarding the confusion between the second paragraph (begining "In the case of a provider-managed or co-managed connection, ...") and the bullet about direction - I think we agreed to delete the paragraph (at least, you asked on the list if anyone objected and I didn't see any replies).  This was issue 9 in my comments on draft-02.
            [Qin]: See discussion we had earlier: https://www.ietf.org/mail-archive/web/l3sm/current/msg00746.html
            I think there is a typo in my response to you. That is to say I think the 2nd paragraph in section 6.12.3.2 is fine, but if we really enhance the 2nd paragraph in section 6.12.3.2 to make it consistent with introduced new   parameter “direction”, I need to get confirmation from L3SM design team, unfortunately I didn’t get feedback on this, that is why I leave as it does. I will ping them again, to see how to enhance the current text.

  *   The provider address and mask are now optional in the case of DHCP, as agreed; however, in the case of static, they are still marked as mandatory.  I think the following leaves need to have mandatory removed as well (issue 11 from draft-02)
     *   l3vpn-service/sites/site/site-network-accesses/site-network-access/ip-connection/ipv4/addresses/provider-address
     *   l3vpn-service/sites/site/site-network-accesses/site-network-access/ip-connection/ipv4/addresses/mask
     *   l3vpn-service/sites/site/site-network-accesses/site-network-access/ip-connection/ipv6/addresses/provider-address
     *   l3vpn-service/sites/site/site-network-accesses/site-network-access/ip-connection/ipv6/addresses/mask
       [Qin]: Your proposed change is fine to me.

  *   In the filters container/choice, we agreed to add 'when' statements for each case based on the type, to prevent invalid combination of the type and filter lists as in the example I posted.  (Issue 13 from draft-02).
[Qin]: Missed this, will add.

  *   For the address-allocation-type leaves, I saw you removed the default (as agreed) but also added 'mandatory true' (which was not discussed).  Making these leaves mandatory does not address the problem - if anything, it makes it worse.  (Issue 15 from draft-02)
[Qin]: Fine to me, it looks we need to seek balance between making all parameters mandatory and making all parameters optional. I hope Jan will be happy with these changes.

Two new comments:

  1.  Under the cloud-access list, the "authorized-sites" and "denied-sites" have been added back in, in draft-03.  These were previously removed because they duplicate the functionality in the 'list-flavour' choice.
   [Qin]: Removed.

  1.  There are a number of leaves that are marked as mandatory or have defaults, which I think should not be - sorry for not raising this earlier, actually it was only just pointed out to me by someone else:
     *   l3vpn-service/sites/site/security/encryption/layer - this should either be optional, or have a 'when' statement that means it only exists when encryption is enabled.  If encryption is disabled, there is no need to specify the layer.
                    [Qin]:I prefer to make it optional.

     *   l3vpn-service/sites/site/security/encryption/encryption-profile/profile – same [Qin]: Fixed.
     *   l3vpn-service/sites/site/service/qos/qos-profile/qos-profile (and same under site-network-accesses) - I'm not sure why this choice is mandatory, that means one of the options has to be specified for both the site and the site-network-access.  I think the intent is that it is optional in both places, so it can be specified in one or the other.
               [Qin]: Fine with me.

     *   l3vpn-service/sites/site/site-network-accesses/site-network-access/service/multicast/multicast-address-family/ipv[46] - IPv4 has default  true but IPv6 has default false; I think they should both be default false.
             [Qin]: Okay.

Thanks,

    David

On 06/09/2017 11:25, Qin Wu wrote:

We have incorporated additional comments from David in v-(03).

https://www.ietf.org/rfcdiff?url2=draft-wu-l3sm-rfc8049bis-03

Thank David, thanks for L3SM design team help complete this.



-Qin

-----邮件原件-----

发件人: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> [mailto:internet-drafts@ietf.org]

发送时间: 2017年9月6日 18:18

收件人: Qin Wu; Luis Tomotaki; Kenichi Ogaki; Stephane Litkowski

主题: New Version Notification for draft-wu-l3sm-rfc8049bis-03.txt





A new version of I-D, draft-wu-l3sm-rfc8049bis-03.txt has been successfully submitted by Qin Wu and posted to the IETF repository.



Name:            draft-wu-l3sm-rfc8049bis

Revision: 03

Title:           YANG Data Model for L3VPN Service Delivery

Document date:   2017-09-06

Group:           Individual Submission

Pages:           181

URL:            https://www.ietf.org/internet-drafts/draft-wu-l3sm-rfc8049bis-03.txt

Status:         https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/

Htmlized:       https://tools.ietf.org/html/draft-wu-l3sm-rfc8049bis-03

Htmlized:       https://datatracker.ietf.org/doc/html/draft-wu-l3sm-rfc8049bis-03

Diff:           https://www.ietf.org/rfcdiff?url2=draft-wu-l3sm-rfc8049bis-03



Abstract:

   This document defines a YANG data model that can be used for

   communication between customers and network operators and to deliver

   a Layer 3 provider-provisioned VPN service.  This document is limited

   to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364.  This

   model is intended to be instantiated at the management system to

   deliver the overall service.  It is not a configuration model to be

   used directly on network elements.  This model provides an abstracted

   view of the Layer 3 IP VPN service configuration components.  It will

   be up to the management system to take this model as input and use

   specific configuration models to configure the different network

   elements to deliver the service.  How the configuration of network

   elements is done is out of scope for this document.



   If approved, this document obsoletes RFC 8049.  The changes are a

   series of small fixes to the YANG module, and some clarifications to

   the text.









Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat





--

David Ball

<daviball@cisco.com><mailto:daviball@cisco.com>