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

From: "Sudhin" <[email-masked]>
Date: 21 Sep 2019 07:00:40 -0000

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: [email-masked] [mailto:[email-masked]]

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

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 23 Sep 2019 07:30:06 +0000

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: [email-masked] [mailto:[email-masked]]
Sent: Saturday, September 21, 2019 9:01 AM
To: Giuseppe Fioccola <[email-masked]>
Cc: [email-masked]
Subject: Re: https://tools.ietf.org/id/draft-ietf-ippm-multipoint-alt-mark-02.txt

Hi Giuseppe,

Regards,
Sudhin

Hi Sudhin,

Regards,

Giuseppe

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

To: Giuseppe Fioccola

Hi Giuseppe,

Regards,

Sudhin

---

From: "Sudhin" <[email-masked]>
Date: 23 Sep 2019 08:35:59 -0000

Hi Giuseppe,

Kindly find the answer inline.

Regards,
Sudhin

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

Hi Sudhin,

Best Regards,

Giuseppe

To: Giuseppe Fioccola 

Cc: [email-masked]

Hi Giuseppe,

Regards,

Sudhin

Hi Sudhin,

Regards,

Giuseppe

To: Giuseppe Fioccola 

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

Hi Giuseppe,

the Introduction.

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

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.

Sudhin>>>>>> Sure Kindly address that

Sudhin>>> Color details are not mentioned.

Sudhin>> ok

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

Regards,

Sudhin

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 23 Sep 2019 09:45:13 +0000

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

Best Regards,

Giuseppe

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

Hi Giuseppe,

Regards,
Sudhin

Hi Sudhin,

Best Regards,

Giuseppe

To: Giuseppe Fioccola

Cc: [email-masked]<mailto:[email-masked]>

Hi Giuseppe,

Regards,

Sudhin

Hi Sudhin,

Regards,

Giuseppe

To: Giuseppe Fioccola

Subject: REG:

Hi Giuseppe,

the Introduction.

[GF]: ok I will address this point.

source routers.

[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.

[GF]: Sure

[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.

Sudhin>> ok

[GF]: great

[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