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

["Sudhin" <[e-mail]>]

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]]


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

To: Giuseppe Fioccola 

Cc: [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]]





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.


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.




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







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.


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



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.








Regards,



Sudhin