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

[Qin Wu <[e-mail]>]

We spin on this issue for quite a while, ☺, please see my reply below.

发件人: David Ball [mailto:[e-mail]]
发送时间: 2017年8月31日 0:54
收件人: Qin Wu; l3sm
抄送: stephane.litkowski; ke-oogaki; adrian
主题: Re: [L3sm] 答复: 答复: New Version Notification for draft-wu-l3sm-rfc8049bis-02.txt

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?

[Qin]: See below.
 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.

[Qin]: We are using different language or term to describe similar thing, e.g.,the service is guaranteed in your saying means the parameters can be enforced the service can be fulfilled in my saying.

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.


[Qin]:RFC8049 clearly says "If CsC is enabled, the requested "svc-mtu" leaf will refer to the
   MPLS MTU and not to the IP MTU. ".

”

There is nothing in the draft that relates the leaf called "svc-mtu" to the length of packets or the behaviour of the service.

[Qin]: The service level svc-mtu parameter will be translated into orchestrated configuration parameter such as path MTU, I think svc-mtu is linking to end to end MTU or path MTU, It is possible for the path MTU to be configured manually or to be discovered dynamically. Path MTU is linking to packet length, the size of any packet in the traffic flow should not exceed svc-mtu value, or
svc-mtu should not exceed path MTU or end to end MTU, otherwise the service will not be enforced or guaranteed.
We also have interface MTU for each network device along the path, but this is not service-level parameter, it is set at each hop along the path. Fragmentation or packet drop, silent or not, may occur on hops along the route where a interface MTU is smaller than the size of the datagram.

    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

<[e-mail]><mailto:[e-mail]>



--

David Ball

<[e-mail]><mailto:[e-mail]>




_______________________________________________

L3sm mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/l3sm



--

David Ball

<[e-mail]><mailto:[e-mail]>