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

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

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.


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.



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.



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.


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.



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.





Regards,

Sudhin