Re: [Gen-art] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09

[Qin Wu <[e-mail]>]

-----邮件原件-----
发件人: Brian E Carpenter [mailto:[e-mail]] 
发送时间: 2017年10月19日 3:26
收件人: Qin Wu; [e-mail]
抄送: [e-mail]; [e-mail]
主题: Re: Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09

On 17/10/2017 14:40, Qin Wu wrote:
...

>> The same is applied to jitter. As clarified in the introduction, the 
>> definition of 'jitter' is used to monitor reachability of destinations, troubleshoot failures, monitor performance.
> 
> Yes, but what *is* jitter physically? There is no scientific definition of 'jitter' in the IETF. Do you mean IPDV as defined in RFC3393 or something else?
> 
> [Qin]:Jitter is packet jitter (https://en.wikipedia.org/wiki/Jitter). 
> You are right, one typical example of packet jitter is IPDV defined in RFC3393, but we don't want to limit it to IPDV, we also allow support other protocol and other measurement methodology, e.g., we could also consider to use MAPDV2 defined in [ITU-T G.1020], what protocol is used and what methodology is used can be indicated by the parameter 'protocol-id' parameter and 'protocol-id-meta-data' in this model.

I don't see how this specification can be used for interoperable implementations unless you define a specific meaning of 'jitter'.

If the network management system assumes RFC3393 but half the routers in the network implement G.1020, there is no interoperability.

[Qin]: Correct, Just to clarify, it is not our intent to encourage implementer to support various different mechanisms to measure jitter in one single solution.
In one single solution, we will restrict to use one mechanism, one protocol to measure jitter, but flexibility we allow here, you might choose different time units,
But again we might only allow one time unit in one single solution, introduce protocol-id parameter is used to allow future protocol and future mechanism to be created then we support different mechanism to measure 
Jitter with different time unit.

> I assume that by 'delay' you mean RFC7679 rather than RFC2681, but that seems straightforward,  and so do the other metrics used in session-packet-statistics and session-error-statistics.
> 
> [Qin]: Correct, it is one way delay instead of two way delay. 

Again - it is useful to specify one-way delay, for interoperability.
(Whether the routers can measure one-way delay is another question; they might be forced to measure RTT and assume delay = RTT/2 .)

[Qin]: Agree, have a second thought, I think with protocol-id, we can decide which kind of delay we are meant to use? E.g.,if protocol-id is set to OWAMP defined in RFC4656, we will use one way delay, if protocol-id is set to TWAMP defined in RFC5357,We will use round trip delay, we allow such flexibility, I might be wrong, since earlier, I claim we only support one way delay, I need to confirm this from other authors.

Regards
    Brian