Re: [Last-Call] [Gen-art] Genart last call review of draft-ietf-ippm-multipoint-alt-mark-06

[Alissa Cooper <[e-mail]>]

Linda, thanks for your review. Giuseppe, thanks for your responses. I entered a No Objection ballot.

Alissa


> On Mar 9, 2020, at 8:34 AM, Giuseppe Fioccola <[e-mail]> wrote:
> 
> Hi Linda,
> Thank you. I will apply the new version later today.
> 
> Regards,
> 
> Giuseppe
> 
> -----Original Message-----
> From: Linda Dunbar [mailto:[e-mail]] 
> Sent: Friday, March 6, 2020 9:01 PM
> To: Giuseppe Fioccola <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Genart last call review of draft-ietf-ippm-multipoint-alt-mark-06
> 
> Giuseppe, 
> 
> Thank you very much for the explanation. It is good. 
> 
> Linda
> 
> -----Original Message-----
> From: Giuseppe Fioccola <[e-mail]> 
> Sent: Friday, March 6, 2020 12:21 PM
> To: Linda Dunbar <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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:[e-mail]] 
> Sent: Friday, March 6, 2020 5:15 PM
> To: Giuseppe Fioccola <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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 <[e-mail]> 
> Sent: Friday, March 6, 2020 3:51 AM
> To: Linda Dunbar <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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:[e-mail]] 
> Sent: Thursday, March 5, 2020 11:20 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art