[L2sm] Followup of RFC8049bis
Qin Wu <bill.wu@huawei.com> Mon, 03 July 2017 09:52 UTC
Return-Path: <bill.wu@huawei.com>
X-Original-To: l2sm@ietfa.amsl.com
Delivered-To: l2sm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3298F12EC18; Mon, 3 Jul 2017 02:52:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 cXwb5cp4T3t0; Mon, 3 Jul 2017 02:52:38 -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 9438F1289C3; Mon, 3 Jul 2017 02:52:37 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJQ32271; Mon, 03 Jul 2017 09:52:35 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 3 Jul 2017 10:52:06 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.25]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Mon, 3 Jul 2017 17:52:01 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "l3sm@ietf.org" <l3sm@ietf.org>, "l2sm@ietf.org" <l2sm@ietf.org>
CC: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "Benoit Claise (bclaise)" <bclaise@cisco.com>
Thread-Topic: Followup of RFC8049bis
Thread-Index: AdLz4gQczWlV+rrbRBePS8Ez8xfWvQ==
Date: Mon, 03 Jul 2017 09:52:00 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9A9956B2@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.78.218]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9A9956B2nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.595A13E3.00F6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 4f3feb204b41f273a8b540d91adafc40
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2sm/qVVq5TJcAXfB2mBPiLvFf3h1QME>
Subject: [L2sm] Followup of RFC8049bis
X-BeenThere: l2sm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" <l2sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2sm>, <mailto:l2sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l2sm/>
List-Post: <mailto:l2sm@ietf.org>
List-Help: <mailto:l2sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2sm>, <mailto:l2sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jul 2017 09:52:40 -0000
Hi, All: The v-(02) of RFC8049bis has just been posted, https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/ thanks Jan and David for valuable comments and input, the main changes include: 1.Specify what type of IPv6 address in the model for IPv6 connection? link-local global 2.Specify provider address and a list of start-end addresses from provider address 3.remove redundant parameters such as deny-any-except and permit-any-except under cloud-access? 4. Add a few text to clarify what the site is in section 6.3 5. Add a few text to clarify why having customer-name. 6. Fixed two typos pointed by Jan recently. Talking with L3Sm design team, we believe how information is communicated by SP to the customer is beyond the scope of RFC8049 has already been clarified in section 6.6, 2nd paragraph, section 6.6.3,2nd paragraph, 1st bullet, 3rd bullet, section 6.12.2.2,4th paragraph. Regarding whether AS number under BGP protocol is supposed to be the customer's AS number or the SP's AS number, we think AS number as part of BGP protocol related parameters are applied to provider to customer boundary, therefore the answer is depending on how the management model is administered. As Jan pointed out, we still have some new mandatory fields introduced in v-(02) haven't been reflected in the examples. But he is okay with the current shape. Please review these changes, let us know if there is any additional comments. Regards! Qin (on behalf of team)