[ippm] R: I: I-D Action: draft-ietf-ippm-alt-mark-01.txt

[Fioccola Giuseppe <[e-mail]>]

Hi Qin,

Thanks for your detailed reviews and valuable suggestions.

I will address your comments in the next version of the draft.



Please see my answers inline.



Best Regards,



Giuseppe



-----Messaggio originale-----

Da: Qin Wu [mailto:[e-mail]]

Inviato: martedì 27 settembre 2016 09:35

A: IETF IPPM WG

Cc: Fioccola Giuseppe

Oggetto: RE: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-01.txt



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.



[GF] I fully agree. These sentences are inherited by oldest version of the draft so are now obsolete. For instance in this version we mention the RFC6374 and Overlay OAM use case where a protocol modification is needed.



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.



[GF] I agree. I will move it 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.



[GF] I agree. I will move it to acknowledgements section.



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?



[GF] It is only applied to color switching based on fixed timer. This is preferable to the method based on a fixed number of packets.

I agree, we need to explain better this concept.

In case we have only clock error between network devices, they must be synchronized to the same clock reference with an accuracy of +/- L/2 time units. In this way, in theory, you are able to recognize the right packet marked batch along your path.

But, in practice, you can have also out of order at batch boundaries, strictly related to the maximum delay between measurement points, so, without considering clock error, we wait L/2 after color switching to be sure to take a still counter.

In summary we have two errors: clock error between network devices and the interval we need to wait to avoid out of order because of network delay. If we consider one-by-one these two problems the limit value is L/2.

If we consider both issues we should say:



-L/2 < (maximum clock error + maximum network delay) < L/2



I want to add this formula in the next version.

This will address also the suggestion from Jose Ignacio during Berlin presentation.



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?



[GF] We can do that also with single marking methodology: we store timestamp of the first or last packet of a batch and that timestamp can be compared with the timestamp of the same packet along the path.

But this option does not work in case of out of order. The option in case of single marking, that escapes out of order issue, is average delay.



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?



[GF] Second marking selects some packets dedicated for delay measurement within first marking. This option works in case of out of order because you can always recognize the second marked packets.

But between this second marked packets we need a security gap in order to avoid out of order issue between these packets.



7. Section 3.3

Can you detail on how delay variation is calculated in this case?



[GF] The calculation of delay variation is similar to the delay. We refer to the definition in RFC 3393. But I will explain how to do in the next version.



8.Section 4.1, paragraph 1

Not sure packet loss measurement requires synchronization between two network devices?



[GF] The strength of this method is that it needs a synchronization accuracy of +/- L/2 (without considering network delay), in this way all network devices consistently match the color bit to the correct block.



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.



[GF] For instance, if you choose a marking interval of 5minutes, you can have all network devices 2m and 30s asynchronous (without considering network delay).



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.



[GF] We need data correlation to compare counters and timestamps for packet loss, delay and jitter calculation. I will add some text to explain better.



11.Section 5

Not sure implementation and deployment is part of this spec, either move them to appendix or removed it from this spec.



[GF] We could move that to appendix.



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?



[GF] This is explained in draft-fioccola-ippm-alt-mark-active. But the application of marking method can simplify also the active measurement and can enable hybrid measurements.



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?



[GF] Both



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.

"



[GF] Thanks for all editorial changes.



-Qin



-----Messaggio originale-----

Da: ippm [mailto:[e-mail]] Per conto di Fioccola Giuseppe

Inviato: giovedì 7 luglio 2016 17:24

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

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:[e-mail]] Per conto di [e-mail]<mailto:[e-mail]>

Inviato: giovedì 7 luglio 2016 16:33

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

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

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

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

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

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

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