Re: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-01.txt
Qin Wu <bill.wu@huawei.com> Tue, 27 September 2016 07:35 UTC
Return-Path: <bill.wu@huawei.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B8912B379 for <ippm@ietfa.amsl.com>; Tue, 27 Sep 2016 00:35:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.537
X-Spam-Level:
X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, 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 4CNydwgihSeV for <ippm@ietfa.amsl.com>; Tue, 27 Sep 2016 00:35:04 -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 D7F4112B3A8 for <ippm@ietf.org>; Tue, 27 Sep 2016 00:35:03 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRZ02011; Tue, 27 Sep 2016 07:34:59 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 27 Sep 2016 08:34:53 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.199]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 27 Sep 2016 15:34:46 +0800
From: Qin Wu <bill.wu@huawei.com>
To: IETF IPPM WG <ippm@ietf.org>
Thread-Topic: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-01.txt
Thread-Index: AQHR2GOkS1kzwnBKcEyj2tK2HIdYDqCD840AgAl5YyA=
Date: Tue, 27 Sep 2016 07:34:46 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA853FF751@nkgeml513-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.78.112]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.57EA2125.019E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.199, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 20e57eea6c649536a149924ac939a310
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/QfNfb3RjjxhA8_PuZqZUFyl7Eo0>
Subject: Re: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-01.txt
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Sep 2016 07:35:07 -0000
Hi, Giuseppe: I have taken a pass on this document and have the following comments and suggestions: Minor issues: 1. Introduction, paragraph 4 said: " It doesn't require any protocol extension or interaction with existing protocols, thus avoiding any interoperability issue. Even if the method doesn't raise any specific need for standardization, it could be further improved by means of some extension to existing protocols, but this aspect is left for further study and it is out of the scope of this document. " Do we really need this paragraph, it confuses me a lot. in the first sentence, it said protocol extension is not needed, in the second sentence, it said extension to existing protocol can be used to improve this method, these two sentences are not consistent, in addition, it said this method doesn't need to be standardized in some case, I am wondering if it doesn't need to be standardized, why produce this document? Suggest to remove these two sentences. 2.Introduction, paragraph 5 said: " The method described in this document, also called PNPM (Packet Network Performance Monitoring), has been invented and engineered in Telecom Italia and it's currently being used in Telecom Italia's network. " I can see this method has been implemented in TI network, but it doesn't need to be emphasized in the introduction and abstract, It make people to feel this spec is TI specific standard, :-),which is not true. I would suggest to remove this statement from spec or move them to implementation report section. 3.Introduction, paragraph 5 said: " The previous IETF drafts about this technique were: [I-D.cociglio-mboned-multicast-pm] and [I-D.tempia-opsawg-p3m]. There are some references to this methodology in other IETF works (e.g. [I-D.ietf-mpls-flow-ident], [I-D.bryant-mpls-sfl-framework] [I-D.bryant-mpls-rfc6374-sfl], [I-D.ietf-bier-mpls-encapsulation], [I-D.mirsky-bier-pmmm-oam] [I-D.chen-ippm-coloring-based-ipfpm-framework]). " It doesn't need to emphasize the history of this document, I would suggest to create acknowledgement section, move text there. 4. Section 3.1 What is clock error? How this is related to wait L/2 time units after color switching based on fixed timer? In this document, it introduce two color switching method, one is based on fixed number of packet, the other is based on fixed timer, I am wondering whether clock error is only applied to color switching based on fixed timer, or applied to both? 5.Section 3.2.3, paragraph 1 Why the second marking is needed? Why we can not calculate minimum and maximum delay based on single marking methodology? 6. Section 3.2.3, paragraph 2 said: " Basically, the idea is to use the first marking to create the alternate flow and, within this colored flow, a second marking to select the packets for measuring delay/jitter . " Is second marking and first marking applied to the same colored flow? Can you give an example to explain what double marking looks like? Why measure jitter is needed in the one way delay measurement? 7. Section 3.3 Can you detail on how delay variation is calculated in this case? 8.Section 4.1, paragraph 1 Not sure packet loss measurement requires synchronization between two network devices? 9.Section 4.1, paragraph 3 said: " The synchronization requirement can be satisfied even with a relatively inaccurate synchronization method. " Give you give an example of inaccurate sync method? This sentence needs to be expanded to add more details. 10. Section 4.2 Why Data correlation is required in this method? It will be great to see some justification text at the beginning of this section before touching data correlation details. 11.Section 5 Not sure implementation and deployment is part of this spec, either move them to appendix or removed it from this spec. 12. Section 6 paragraph 1 said: " The method has been explicitly designed for passive measurements but it can also be used with active measurements . " This section seems not discuss how method is used in the active measurement? Why active measurement should use this method? 13. Section 6 paragraph 1 said: " In order to have both end to end measurements and intermediate measurements (hybrid measurements ) two end points can exchanges artificial traffic flows and apply alternate marking over these flows. In the intermediate points artificial traffic is managed in the same way as real traffic and measured as specified before. " Is hybrid measurement about combination of passive measurement and active measurement or combination of end to end measurement and intermediate measurement? Editorial issues and Nits 1. Section 1, 3rd paragraph: OLD TEXT: " A lot of work related to OAM, that includes also performance monitoring techniques, has been done by Standards Developing Organizations: " NEW TEXT: " A lot of work related to OAM, that includes also performance monitoring techniques, has been done by Standards Developing Organizations(SDOs): " 2.Section 1, 3rd paragraph OLD TEXT: " The IPPM WG has defined standard metrics to measure network performance; however, the methods developed in the WG mainly refer to refer to active measurement techniques. " NEW TEXT: " The IPPM WG has defined standard metrics to measure network performance; however, the methods developed in this WG mainly refer to focus on active measurement techniques. " 3.Section 4.2 and 4.3 2nd paragraph OLD TEXT: " In the following paragraphs an example data correlation mechanism is explained and could be use independently of the adopted solutions. " NEW TEXT: " In the following paragraphs an example of data correlation mechanism is explained and could be use independently of the adopted solutions. " 4.Section 9 OLD TEXT: " The method doesn't raise any specific need for standardization, but it could be further improved by means of some extension to existing protocols. " NEW TEXT: " The method doesn't raise any specific need for protocol extension, but it could be further improved by means of some extension to existing protocols. " -Qin -----Messaggio originale----- Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di Fioccola Giuseppe Inviato: giovedì 7 luglio 2016 17:24 A: ippm@ietf.org; ippm-chairs@tools.ietf.org Oggetto: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-01.txt Hi All, This new version of draft-ietf-ippm-alt-mark includes part of the contents of draft-chen-ippm-coloring-based-ipfpm-framework. The authors have merged some Sections regarding Re-ordering Tolerance, Synchronization Aspects, Security Considerations and other general concepts. Best Regards, Giuseppe -----Messaggio originale----- Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di internet-drafts@ietf.org Inviato: giovedì 7 luglio 2016 16:33 A: i-d-announce@ietf.org Cc: ippm@ietf.org Oggetto: [ippm] I-D Action: draft-ietf-ippm-alt-mark-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics of the IETF. Title : Alternate Marking method for passive performance monitoring Authors : Giuseppe Fioccola Alessandro Capello Mauro Cociglio Luca Castaldelli Mach(Guoyi) Chen Lianshu Zheng Greg Mirsky Tal Mizrahi Filename : draft-ietf-ippm-alt-mark-01.txt Pages : 29 Date : 2016-07-07 Abstract: This document describes a passive method to perform packet loss, delay and jitter measurements on live traffic. This method is based on Alternate Marking (Coloring) technique. A report on the operational experiment done at Telecom Italia is explained in order to give an example and show the method applicability. This technique can be applied in various situations as detailed in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ippm-alt-mark-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-alt-mark-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm
- Re: [ippm] I: I-D Action: draft-ietf-ippm-alt-mar… Qin Wu
- [ippm] R: I: I-D Action: draft-ietf-ippm-alt-mark… Fioccola Giuseppe