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

David Ball <daviball@cisco.com> Wed, 30 August 2017 16:54 UTC

Return-Path: <daviball@cisco.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 84FD71321E3 for <l3sm@ietfa.amsl.com>; Wed, 30 Aug 2017 09:54:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 ehJ6MZc8aE8O for <l3sm@ietfa.amsl.com>; Wed, 30 Aug 2017 09:54:21 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82081321B7 for <l3sm@ietf.org>; Wed, 30 Aug 2017 09:54:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13389; q=dns/txt; s=iport; t=1504112060; x=1505321660; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=PiCq94UkwIohpNtYYnalifTBPj/clr1y2daUTp+WEDw=; b=F9Ddoxlp2GWKXQEtjz35T/xwW5epCip9p0NgZu9BB5WmrPmhIAHiM7BO nywSlj/0PPkniz6a4Uh+/N1jp+L2XKU00n2+DCUypmF+crjaLWVIq2cEl gSXbeschi1TonoU7EOmdka8gXX7xvVmJn1GpK+BYMLW2O7JZ8NvYHfEY5 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AgAgBf7KZZ/xbLJq1eGQEBAQEBAQEBAQEBBwEBAQEBgm+BT4EVg3eLEpEXkGlRhn8hAQqFGwKEahQBAgEBAQEBAQFrKIUYAQEBAQIBAQEhSwkCBQsJAg4KKgICJyULBgEMBgIBAYolCBCOfJ1mgicnixsBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMqg1CBYyuCfYRPgzmCYQWRJY9HlEyLUocZjVCIczYhgQ0yIQgcFUmFGBwZGYE2PzaITIJAAQEB
X-IronPort-AV: E=Sophos;i="5.41,449,1498521600"; d="scan'208,217";a="654288144"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2017 16:54:16 +0000
Received: from [10.63.68.124] ([10.63.68.124]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v7UGsFRu007750; Wed, 30 Aug 2017 16:54:16 GMT
To: Qin Wu <bill.wu@huawei.com>, l3sm <l3sm@ietf.org>
Cc: "stephane.litkowski" <stephane.litkowski@orange.com>, ke-oogaki <ke-oogaki@kddi.com>, adrian <adrian@olddog.co.uk>
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> <etPan.59a6d3b2.6b8b4567.242c@Qin-Wude-iPhone>
From: David Ball <daviball@cisco.com>
Message-ID: <60ed4ba7-d1f1-c2d5-591a-efc2ccbd4ad6@cisco.com>
Date: Wed, 30 Aug 2017 17:54:15 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <etPan.59a6d3b2.6b8b4567.242c@Qin-Wude-iPhone>
Content-Type: multipart/alternative; boundary="------------C79ED6FBC23DF092AE9E884D"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/l3sm/hMKelROKDdkZfsV2uhUq7cmjonw>
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, 30 Aug 2017 16:54:23 -0000

On 30/08/2017 16:03, Qin Wu wrote:
> What customer cares about is whether a service parameter can be enforced or used to create a service successfully,

Agreed.  How can this be done if the customer does not know what the 
parameter means?

>  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?!

He doesn't care about whether a specific range should or shouldn't be 
discarded, but he does want to know that the packets he cares about are 
guaranteed not to be discarded.  That is presumably why he would pick a 
particular value for the svc-mtu.  For example, if the customer requests 
svc-mtu to 9000, that presumably means that they want to be sure that 
packets of size up to 9000 will not be discarded.  (Of course, if SP 
can't support that, they will reject the request).  OTOH if the customer 
requests 1400, that presumably means they don't care about packets 
bigger than that (but even so, the SP might still pass packets of length 
9000).

> The earlier proposal is just to specify such behavior from customer perspective.

I didn't see that.  The last proposal just said that if the SP can't 
fulfil the request then they can reject it, which is true for all 
leaves; it didn't say anything about what "svc-mtu" means to the 
customer.  There is nothing in the draft that relates the leaf called 
"svc-mtu" to the length of packets or the behaviour of the service.


     David


>
>
> 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>
>
> -- 
> David Ball
> <daviball@cisco.com>
>
>
> _______________________________________________
> L3sm mailing list
> L3sm@ietf.org
> https://www.ietf.org/mailman/listinfo/l3sm

-- 
David Ball
<daviball@cisco.com>