Giuseppe, 

Thank you very much for the explanation. It is good. 

Linda

-----Original Message-----
From: Giuseppe Fioccola <giuseppe.fiocc...@huawei.com> 
Sent: Friday, March 6, 2020 12:21 PM
To: Linda Dunbar <linda.dun...@futurewei.com>; gen-art@ietf.org
Cc: draft-ietf-ippm-multipoint-alt-mark....@ietf.org; i...@ietf.org; 
last-c...@ietf.org
Subject: RE: Genart last call review of draft-ietf-ippm-multipoint-alt-mark-06

Hi Linda,
Thanks for the feedback!
I will submit the new version by Monday.
Regarding your question, with multipoint path the egress nodes receive 
alternative marked packets in random order from different ingress nodes, but 
the reordering does not affect the measurement if it is satisfied the condition 
in Section 7 that takes into account clock errors, misalignment between marking 
interval and network delay. If we want to recognize the marked signal from a 
specific source node we need to specify better the flow filter criteria (i.e. 
5-tuple), while if we want only to select packets from a specific source (e.g. 
for delay measurements) it is possible to apply the hashing technique as 
mentioned in Section 8.2.2. As an alternative, to identify the source nodes and 
if there is enough space in the header, the Node ID, as you suggested, could be 
a possibility and also the Flow ID could be used to facilitate the 
correlations, but this is an implementation issue and it is not considered 
within this document.

Please let me know if this answers your question and if you want me to include 
these considerations within the draft.

Regards,

Giuseppe


-----Original Message-----
From: Linda Dunbar [mailto:linda.dun...@futurewei.com] 
Sent: Friday, March 6, 2020 5:15 PM
To: Giuseppe Fioccola <giuseppe.fiocc...@huawei.com>; gen-art@ietf.org
Cc: draft-ietf-ippm-multipoint-alt-mark....@ietf.org; i...@ietf.org; 
last-c...@ietf.org
Subject: RE: Genart last call review of draft-ietf-ippm-multipoint-alt-mark-06

Giuseppe, 

Thank you very much for the response. Agree with your proposed changes. 
Just one more question, I remember that the P2P Alternative Marking is achieved 
by sequence of 1 and sequence of 0. So the receiver can detect the change when 
the Marking  changes between 1 and 0. But with multi-point to multi-point 
traffic, the receivers will receive packets from different ingress nodes. If 
the Ingress nodes do not leave their node IDs in the packets, the packets will 
carry Marking of 1 and 0 not in specific orders. 
How does ingress signal to the egress nodes in the multi-point and multi point 
scenario? 

Thank you very much. 

Linda Dunbar
-----Original Message-----
From: Giuseppe Fioccola <giuseppe.fiocc...@huawei.com> 
Sent: Friday, March 6, 2020 3:51 AM
To: Linda Dunbar <linda.dun...@futurewei.com>; gen-art@ietf.org
Cc: draft-ietf-ippm-multipoint-alt-mark....@ietf.org; i...@ietf.org; 
last-c...@ietf.org
Subject: RE: Genart last call review of draft-ietf-ippm-multipoint-alt-mark-06

Dear Linda,
Thanks for your review!
Please find my answers inline tagged as [GF].
Let me know if you agree with my proposed small changes to the draft.

Regards,

Giuseppe


-----Original Message-----
From: Linda Dunbar via Datatracker [mailto:nore...@ietf.org] 
Sent: Thursday, March 5, 2020 11:20 PM
To: gen-art@ietf.org
Cc: draft-ietf-ippm-multipoint-alt-mark....@ietf.org; i...@ietf.org; 
last-c...@ietf.org
Subject: Genart last call review of draft-ietf-ippm-multipoint-alt-mark-06

Reviewer: Linda Dunbar
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C66bb5dda7e1c481bb36008d7c1fb1ba9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637191156559562241&amp;sdata=pCAbPv0ZpCbyHGTILFEZbyGg9U0xZ3hdAKF7o9fGEiY%3D&amp;reserved=0>.

Document: draft-ietf-ippm-multipoint-alt-mark-06
Reviewer: Linda Dunbar
Review Date: 2020-03-05
IETF LC End Date: 2020-03-06
IESG Telechat date: 2020-03-12

Summary:
This document is to expand P2P flows marking methodology to measure unicast 
flows in  multipoint-to-multipoint network. The mechanism is quite interesting.

[GF]: Thanks!

However, I do have some questions:

Page 9 (Section 5: Multipoint Packet Loss): Second paragraph stating that "the 
sum of the number of packets on all ingress interfaces equals the number on the 
egress interfaces for the monitored flow".

how to measure? with all nodes having different timer, it would be difficult to 
quantify the time period. At any given time T, egress node may count packets 
entered at T-x. Where to draw the line? packets may traverse different routes 
through the network, and can take different time.

[GF]: I understand your point but in this case the assumption is the use of the 
alternate marking method. The time reference is given by the alternate marking 
method, where the marking change is an auto-synchronization signal for the 
network nodes. There are also timing aspects due to the different timer of the 
nodes and this is explained in Section 7: Timing Aspects. I can specify that 
this paragraph is valid in the case of alternate marking.

Section 6.1 Algorithm for Cluster Partition:
How do you partition the cluster if the Application ingress the network via 
different nodes?

[GF]: Once defined an Application flow, the algorithm considers all the 
possible links and nodes for the given flow, even if there is no traffic. It is 
based on topological information. So, if the Application ingress via different 
nodes, the counters has a non-zero value for these nodes, while a zero value 
for the other nodes without traffic, but, in the end the formula is still valid.

Major issues: None
Minor issues: None

Nits/editorial comments:

Page 5: first sentence on the policies to classify flows: should allow 
additional conditions that are not in the packet header as part of matching 
criteria

[GF]: Sure, I can add a consideration here that the flow can be defined at 
different levels based on the encapsulation considered and additional 
conditions are possible.

Thank you very much.

Linda Dunbar


_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to