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