-----邮件原件----- 发件人: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] 发送时间: 2017年10月26日 3:23 收件人: Alissa Cooper; Qin Wu 抄送: gen-art@ietf.org; draft-ietf-lime-yang-connectionless-oam-methods....@ietf.org; l...@ietf.org 主题: Re: [Gen-art] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09
A small response in line below: On 26/10/2017 04:16, Alissa Cooper wrote: > Brian, thank you for your review. Qin, thanks for your responses. I have > entered a No Objection ballot that captures the remaining open issue > concerning one-way vs. two-way delay. One further comment below. > >> On Oct 18, 2017, at 9:09 PM, Qin Wu <bill...@huawei.com> wrote: >> >> -----邮件原件----- >> 发件人: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] >> 发送时间: 2017年10月19日 3:26 >> 收件人: Qin Wu; gen-art@ietf.org >> 抄送: draft-ietf-lime-yang-connectionless-oam-methods....@ietf.org; >> l...@ietf.org >> 主题: 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. > > I believe this is well-specified in draft-ietf-lime-yang-connectionless-oam: Yes. Maybe it would help to mention in the Introduction of ietf-lime-yang-connectionless-oam-methods that some elements of the data model are fully defined in ietf-lime-yang-connectionless-oam. The current text says "It is separated from the generic YANG model for connectionless OAM" but does not tell the reader to go and read the generic model! [Qin]: Good suggestion, we will consider this. Thanks. Brian > > grouping session-jitter-statistics { > description > "Grouping for per session jitter statistics"; > container session-jitter-statistics { > description > "Session jitter summarised information. By default, > jitter is measured using IP Packet Delay Variation > (IPDV) as defined in RFC3393 <https://tools.ietf.org/html/rfc3393>. > When the other measurement > method is used instead(e.g., Packet Delay Variation used in > Y.1540, it can be indicated using protocol-id-meta-data > defined in RPC operation of > draft-ietf-lime-yang-connectionless-oam-methods > <https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-methods>. > Note that > only one measurement method for jitter is specified > for interoperability reason."; > > Alissa > >> >> [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 >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
