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

Qin Wu <bill.wu@huawei.com> Wed, 30 August 2017 15:03 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 493E81329AD for <l3sm@ietfa.amsl.com>; Wed, 30 Aug 2017 08:03:29 -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, 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 z0AkBGuH-xvK for <l3sm@ietfa.amsl.com>; Wed, 30 Aug 2017 08:03:22 -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 4A024132644 for <l3sm@ietf.org>; Wed, 30 Aug 2017 08:03:21 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DUL71554; Wed, 30 Aug 2017 15:03:19 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 30 Aug 2017 16:03:18 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.219]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 30 Aug 2017 23:03:14 +0800
From: Qin Wu <bill.wu@huawei.com>
To: l3sm <l3sm@ietf.org>, daviball <daviball@cisco.com>
CC: "stephane.litkowski" <stephane.litkowski@orange.com>, ke-oogaki <ke-oogaki@kddi.com>, adrian <adrian@olddog.co.uk>
Thread-Topic: 答复: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt
Thread-Index: AQHTIaEakD4xS6tx5UydO9dpRoMV6g==
Date: Wed, 30 Aug 2017 15:03:14 +0000
Message-ID: <etPan.59a6d3b2.6b8b4567.242c@Qin-Wude-iPhone>
References: <B8F9A780D330094D99AF023C5877DABA9AA5D7A2@nkgeml513-mbx.china.huawei.com> <c76328ad-b71e-b2a3-92a4-b02beac2be7d@cisco.com> <B8F9A780D330094D99AF023C5877DABA9AAB78D5@nkgeml513-mbx.china.huawei.com> <e3289dda-b54f-6001-d4df-4ad6f43cbc91@cisco.com> <B8F9A780D330094D99AF023C5877DABA9AACC436@nkgeml513-mbx.china.huawei.com> <6acab373-d50e-674e-1f8a-b95363ae7e4b@cisco.com> <B8F9A780D330094D99AF023C5877DABA9AAD04B2@nkgeml513-mbx.china.huawei.com> <bbb82618-18c6-70d1-9a3d-a4cade93535f@cisco.com> <B8F9A780D330094D99AF023C5877DABA9AAD9734@nkgeml513-mbx.china.huawei.com> <c5973f02-1d11-9424-62d3-f8e5e8bf5316@cisco.com> <etPan.59a6b04e.327b23c6.23ea@Qin-Wude-iPhone>, <f60c9b74-8340-f865-c4d5-e1fc3f32bb74@cisco.com>
In-Reply-To: <f60c9b74-8340-f865-c4d5-e1fc3f32bb74@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_etPan59a6d3b26b8b4567242cQinWudeiPhone_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.59A6D3B7.0150, 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: 026052a1776670fdde04542126787687
Archived-At: <https://mailarchive.ietf.org/arch/msg/l3sm/3cLMReSfyYd-PDgDr9dqYCJ_Wrw>
Subject: [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, 30 Aug 2017 15:03:29 -0000

What customer cares about is whether a service parameter can be enforced or used to create a service successfully, why he has to care about how operator use this parameter to control or operate the network or whether specific range should or should not be discarded,isn't this up to SP to implement this details?!
The earlier proposal is just to specify such behavior from customer perspective.


Sent from HUAWEI AnyOffice
发件人: daviball
收件人: Qin Wu; l3sm;
抄送: stephane.litkowski; ke-oogaki; adrian;
主题: Re: 答复: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt
时间: 2017-08-30 22:28:28



Right, but that would still be true if the leaf was called svc-flagglestops and there was a flagglestop limit set by the network.  :)

My question is what specific behaviour is the customer requesting or expecting by setting svc-mtu to a specific value?  Assuming the SP accepts the request, there is presumably some resulting difference in behaviour for packets shorter than the requested value vs packets longer than the requested value?  If so, what is it?  For instance, is it that packets with length <= svc-mtu will not be discarded due to their length, whereas packets with length > svc-mtu might be?

Right now, the draft does not say anything about the meaning of the svc-mtu leaf - one can infer from the name of the leaf that it has something to do with packet length, but the details are not specified.  As Jan said: "For a standard to be useful/interoperable, the system behavior needs to be predictable. Undefined behavior needs to become defined or outlawed.".  There is no behaviour defined for the svc-mtu leaf currently - that is the problem I would like to see addressed.


    David


On 30/08/2017 13:32, Qin Wu wrote:
It means the requested svc-MTU exceeds MTU limit set by the network, the management system may trigger some MTU discovery mechanism to check this.


Sent from HUAWEI AnyOffice
发件人: daviball
收件人: Qin Wu; l3sm;
抄送: stephane.litkowski; ke-oogaki; adrian;
主题: Re: [L3sm] New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt
时间: 2017-08-30 19:09:33


Hi Qin,

On 28/08/2017 11:13, Qin Wu wrote:
[DB3] I completely agree; my point is to provide some information to the customer about how the service might behave if they request a particular value for the MTU.

[Qin-3]: I prefer to keep as it does, but if you insist, we can consider to add something like this:
“if the requested svc-mtu cannot be fulfilled, the management system should return a error message indicating the fulfillment is not possible.  How this SHOULD be communicated by the SP to the customer via a mechanism that is out of scope for this document.”

This doesn't really address my point.  What does it mean for the requested svc-mtu to be fulfilled?  What behaviour is the customer actually requesting by setting this leaf to a particular value?


    David


--
David Ball
<daviball@cisco.com><mailto:daviball@cisco.com>


--
David Ball
<daviball@cisco.com><mailto:daviball@cisco.com>