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.fioccola@xxxxxxxxxx> Sent: Friday, March 6, 2020 3:51 AM To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>; gen-art@xxxxxxxx Cc: draft-ietf-ippm-multipoint-alt-mark.all@xxxxxxxx; ippm@xxxxxxxx; last-call@xxxxxxxx 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:noreply@xxxxxxxx] Sent: Thursday, March 5, 2020 11:20 PM To: gen-art@xxxxxxxx Cc: draft-ietf-ippm-multipoint-alt-mark.all@xxxxxxxx; ippm@xxxxxxxx; last-call@xxxxxxxx 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&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cdeaaf529cb394fe4ed1a08d7c1b3d3ba%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637190850411062631&sdata=uaQYvFu6W40Dj%2Btjq7vKlOhaDSoKfURTFn02DucNe0I%3D&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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
