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

Qin Wu <bill.wu@huawei.com> Wed, 09 August 2017 10:40 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 99EE8126B6D for <l3sm@ietfa.amsl.com>; Wed, 9 Aug 2017 03:40:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 pD0khhPpzrAO for <l3sm@ietfa.amsl.com>; Wed, 9 Aug 2017 03:40:48 -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 5CDFE1320CF for <l3sm@ietf.org>; Wed, 9 Aug 2017 03:40:46 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DTA56181; Wed, 09 Aug 2017 10:40:44 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 9 Aug 2017 11:40:43 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.9]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 9 Aug 2017 18:40:40 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "l3sm@ietf.org" <l3sm@ietf.org>, David Ball <daviball@cisco.com>
CC: Kenichi Ogaki <ke-oogaki@kddi.com>, Stephane Litkowski <stephane.litkowski@orange.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Thread-Topic: New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt
Thread-Index: AQHTEPkPvtKnYeVf5kqBvex8Emv4lqJ70Dmg
Date: Wed, 09 Aug 2017 10:40:39 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9AA5D7A2@nkgeml513-mbx.china.huawei.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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.598AE6AC.0138, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.9, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 436d721ac82f2f52778f0c0e89f858c7
Archived-At: <https://mailarchive.ietf.org/arch/msg/l3sm/Nqng7zzy0FPTQh5b_8ShLP7hhKU>
Subject: Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-02.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: Wed, 09 Aug 2017 10:40:50 -0000

Here is the update to draft-wu-l3sm-rfc8049bis-02 based on additional discussion on the list.
https://www.ietf.org/internet-drafts/draft-wu-l3sm-rfc8049bis-02.txt
Thank David for additional comments. Thank Design team to help address these comments.
The main changes include:
1.Clarify the rational of the model in the section 5 based on David's comment.  
2.Add multi-filter and multi-VPN per entry support for VPN policy.  
3.Modify description for svc-input-bandwidth leaf and svc-output- 
Bandwidth leaf to address inconsistency issue with the text in section 6.12.1. 
4. Add text to clarify the way to achieve Per-VPN QoS policy.
5. Remove address-scope-type since there is no common understanding on this.
6. Modify the description of autonomous-system under container “BGP” to address David's comment on AS.

Regarding provider address and mask to the model for the DHCP and DHCP relay cases, talking with design team members,
We believe these parameters are the one requested by Customer to Provider and therefore we keep it in the model.

Regarding Number of BGP sessions, eBGP multihop between loopbacks and other similar issue, The design team agreed that it is not
reasonable to enumerate all the cases this models doesn't support. The current text has been clear about this.

We believe that we have address all the comments. Thanks!

-Qin
-----邮件原件-----
发件人: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
发送时间: 2017年8月9日 18:20
收件人: Qin Wu; Luis Tomotaki; Kenichi Ogaki; Stephane Litkowski
主题: New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt


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

Name:		draft-wu-l3sm-rfc8049bis
Revision:	02
Title:		YANG Data Model for L3VPN Service Delivery
Document date:	2017-08-09
Group:		Individual Submission
Pages:		181
URL:            https://www.ietf.org/internet-drafts/draft-wu-l3sm-rfc8049bis-02.txt
Status:         https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/
Htmlized:       https://tools.ietf.org/html/draft-wu-l3sm-rfc8049bis-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-wu-l3sm-rfc8049bis-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-wu-l3sm-rfc8049bis-02

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