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 <giuseppe.fiocc...@huawei.com> > wrote: > > Hi Linda, > Thank you. I will apply the new version later today. > > Regards, > > Giuseppe > > -----Original Message----- > From: Linda Dunbar [mailto:linda.dun...@futurewei.com] > Sent: Friday, March 6, 2020 9:01 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 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&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C66bb5dda7e1c481bb36008d7c1fb1ba9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637191156559562241&sdata=pCAbPv0ZpCbyHGTILFEZbyGg9U0xZ3hdAKF7o9fGEiY%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 > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
