Re: [ippm] https://tools.ietf.org/id/draft-ietf-ippm-multipoint-alt-mark-02.txt

[Giuseppe Fioccola <[e-mail]>]

Hi Sudhin,
Please find my answers inline tagged as [GF].
Let me know if this clarify.

Best Regards,

Giuseppe

From: [e-mail] [mailto:[e-mail]]
Sent: Monday, September 23, 2019 10:36 AM
To: Giuseppe Fioccola <[e-mail]>
Cc: [e-mail]
Subject: Re: https://tools.ietf.org/id/draft-ietf-ippm-multipoint-alt-mark-02.txt

Hi Giuseppe,

Kindly find the answer inline.

Regards,
Sudhin

On Mon, 23 Sep 2019 13:00:12 +0530 Giuseppe Fioccola wrote
>







Hi Sudhin,
No problem and thank you for posting our exchange.
Please let me know if this clarify and if you have additional comments.

Best Regards,

Giuseppe

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


Sent: Saturday, September 21, 2019 9:01 AM

To: Giuseppe Fioccola

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

Subject: Re: https://tools.ietf.org/id/draft-ietf-ippm-multipoint-alt-mark-02.txt

Hi Giuseppe,



Let me thank you for the reply. Let me go through it and I will get back.



Regards,

Sudhin



On Thu, 19 Sep 2019 14:23:33 +0530 Giuseppe Fioccola wrote

>















Hi Sudhin,

Thank you for your very useful review. You can find my answers inline tagged as [GF].

Please let me know if this clarify.

If yes, you may want to publish your questions to the IPPM mailing list.



Regards,



Giuseppe



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





Sent: Monday, September 16, 2019 11:04 AM



To: Giuseppe Fioccola



Subject: REG:
https://tools.ietf.org/id/draft-ietf-ippm-multipoint-alt-mark-02.txt



Hi Giuseppe,







I had gone through the draft. Could you please clarify the following.











1. The BUM traffic is very significant in the network, could you please let me know the reason for





excluding it. Excluding that the accuracy of traffic measurement is affected.

[GF]: Agree, BUM traffic is significant and it is not excluded here. It can be monitored by using the


basic RFC 8321, since RFC 8321

applies to point-to-point unicast flows and BUM traffic. The Multipoint alternate marking and its


Clustering approach is valid for multipoint-to-multipoint unicast flows. I will highlight it better in


the Introduction.


Sudhin>>>>>>>>> yes it would be better, BUM traffic measurement is very much needed.

[GF]: ok I will address this point.


2. Could you please let me know how the out of order packet are handled.

[GF]: Out of order packets happen and are handled by

reducing consequently the available counting interval. These aspects are described in Section 7. In


particular three different possible constraints are considered: clock error between

network devices, network delay between measurement points and the misalignment between the marking


source routers.


Sudhin>>>>>> since there is no in band mechanism, how to know the when the flow started at router PE1
and when it reached PE2, there is no time stamp field. How to calculate the delta.

[GF]: In band OAM is just a mechanism that can be used to transmit the information and the timestamp transmission is out of scope here. As for RFC 8321, you have different options: you can transmit the timestamps by using IOAM, PBT-I, PBT-M, or you can send to a controller that can collect all the timestamps and do the calculation. As extension of RFC 8321, this is a methodology draft and the implementation is open. Some words about that can be useful.


3. There will be ECMP paths, how this measurement will take care of it.

[GF]: ECMP paths are point-to-multipoint unicast flows so, by definition, they can be easily monitored


with this technique. I will

add a sentence on this in the Introduction or in Section 3.

Sudhin>>>>>> Sure Kindly address that

[GF]: Sure



4. How do we collect the data, the draft is silent of flow measurement.

[GF]: The draft aims to define especially the methodology as the extension of RFC 8321. However,


Section 9 introduces the idea of

an Intelligent Performance Management and suggests that an SDN Orchestrator or a Controller can apply


this methodology since it is aware of the network topology. In addition, Section 3 introduces the


generalization of the flow definition.


Sudhin>>> Color details are not mentioned.

[GF]: As for RFC 8321, you can classify the traffic and mark a portion of the traffic. For each period you are aware of the number of packets and so you know rate and bandwidth. In this way you can understand if the traffic rate overcomes limits. If you need more precision you can reduce the marking period. Some implementations use a marking period of 1 sec and less. I will add a sentence.


5. What will happen when re write rules are applied which gives an erroneous output isnt it.

[GF]: Yes, there is a transient time to wait once new rules are configured and it can be determined by


the network management. I

can add a sentence on this in Section 9.



Sudhin>> ok

[GF]: great



6. In delay measurement, the draft didnt explain the start of the time measurement, the networks





elements are not synced properly there will be a delta. Since there is no explicit signalling of





timestamp. could you please explain how this is done.

[GF]: The delay measurements can be done similarly to RFC 8321. The marking batches anchor the samples


to a particular period so

this is the time reference that can be used (each block of packets can also be numbered if needed). As


reported in Section 7, compared to RFC 8321, the only additional contribution to consider is the


misalignment between the marking source routers and, as

you said, there is a delta that reduces the available measurement interval. I can specify in the


Section 8 that the timing aspects applies to delay measurements as well.


Sudhin>>>>>> please since there is no timestamp counter, it would be difficult to measure delay and
delay variations.

[GF]: As previously said, the network elements take the timestamps and how to transmit them is out of scope here and can be done in several ways (IOAM, PBT-I, PBT-M).






Regards,



Sudhin