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

Linda Dunbar <linda.dunbar@futurewei.com> Fri, 06 March 2020 16:15 UTC

Return-Path: <linda.dunbar@futurewei.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728963A0A21; Fri, 6 Mar 2020 08:15:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.9
X-Spam-Level: **
X-Spam-Status: No, score=2.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_SUMOF=5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4G8iJlJRlcn1; Fri, 6 Mar 2020 08:15:06 -0800 (PST)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2109.outbound.protection.outlook.com [40.107.244.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083203A0A1F; Fri, 6 Mar 2020 08:15:05 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DjSuJgyFnxU874ZvxHaQ58/u0emP+symgVJodkGSirB+xJxBb9Jg2MN6i4YKHY?= =?utf-8?q?Hrr3uIMb05FC3HconmZTV63FxHTyXtTrMmXt/ys5ybHG1VX2RRuNRFNshdeA2Dzkh?= =?utf-8?q?lMrBhYenTd0e2IULdzcSwdZMg2Wn1bB/WVaS3c0uofBJjQ5dHW/e7UT4yN5T2CI8w?= =?utf-8?q?mKCRiqwPFmifz+tizZrWUVP8poLDUETRCf2QbJ0NPoevhZvELwQOtVqlYBrf9ol52?= =?utf-8?q?OwxYMEqXeZAvuqVI2OumKIGYSZoSbLkLpHv1BA2iiQO1ADngmozQi/5AtNqgpJtG2?= =?utf-8?q?1gFOpGiF/SB4LFIVu9sJA=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?= =?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DcDIOG+Q3sUpZ2QKDBUPVeEDV4dnswaipar1y9RIS1/4=3D=3B_b=3DFWTBCR?= =?utf-8?q?2K9ZoFN4D8wp5S2jo01AXxSkA4I5oIXB8oZYn9HSMdIBSF9JtDYlcPM8meD6iZiVk?= =?utf-8?q?aLj5Nm+WgeWLooKDjI0HnhOtXnyewxtNIG1BcyrULI6O4poFSnFVimawz0zoMnhCr?= =?utf-8?q?NY5VdZXk9L50ZrQ1tMi/irwQC/sKa/RaoIWHp9pYr+oALQkKhPrOS4MK3BPJTKlpO?= =?utf-8?q?KQkdPkTU69w4JGkS1bO/hdiC+LSxExgLize2J2dcbcpJdBYrPbZKf5EZiDKD1rorK?= =?utf-8?q?yWC9MCBAEjeBu3rhQ/qooGAY1IA/RX+jA7lmRPZRTYdq5kh4zox8HMAQbAAzyL+ve?= =?utf-8?q?zi5mE6Y9UGA=3D=3D?=
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3AContent-Typ?= =?utf-8?q?e=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DcDIOG+Q3sUpZ2QKDBUPVeEDV4dnswaipar1y9RIS1/4=3D=3B_b=3DHxqWov?= =?utf-8?q?lQge4PE7nXexI7R4+lXaZ6t+wPhkzGfbec6YfpHuwSfFTQwmmHH30mgNt+8ypebDo?= =?utf-8?q?FaRsWvZiX1IZdscfJWwPJn1Ut+SbkP5V+WKBQOBrcVhIXOoTMsf8UcrkbhWrGs46m?= =?utf-8?q?ZwdrVUsuuY18HRpZsgvoIdrx4NYofxNKAPI=3D?=
Received: from MWHPR1301MB2096.namprd13.prod.outlook.com (2603:10b6:301:34::35) by MWHPR1301MB2158.namprd13.prod.outlook.com (2603:10b6:301:2b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.11; Fri, 6 Mar 2020 16:15:04 +0000
Received: from MWHPR1301MB2096.namprd13.prod.outlook.com ([fe80::e893:a912:1d3a:5a33]) by MWHPR1301MB2096.namprd13.prod.outlook.com ([fe80::e893:a912:1d3a:5a33%6]) with mapi id 15.20.2793.013; Fri, 6 Mar 2020 16:15:04 +0000
From: Linda Dunbar <linda.dunbar@futurewei.com>
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, "gen-art@ietf.org" <gen-art@ietf.org>
CC: "draft-ietf-ippm-multipoint-alt-mark.all@ietf.org" <draft-ietf-ippm-multipoint-alt-mark.all@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: Genart last call review of draft-ietf-ippm-multipoint-alt-mark-06
Thread-Index: AQHV85yyi+K9rmRSAUezQQTnbahtWqg7vB3g
Date: Fri, 6 Mar 2020 16:15:04 +0000
Message-ID: =?utf-8?q?=3CMWHPR1301MB209609A6C565A653FD477AA585E30=40MWHPR130?= =?utf-8?q?1MB2096=2Enamprd13=2Eprod=2Eoutlook=2Ecom=3E?=
References: <158344682412.14483.3670919728514853196@ietfa.amsl.com> <c2a9f53b801348d0bdc358ef1f7a41e6@huawei.com>
In-Reply-To: <c2a9f53b801348d0bdc358ef1f7a41e6@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=linda.dunbar@futurewei.com;
x-originating-ip: [12.111.81.95]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1c39d897-6df6-4827-098a-08d7c1e987e2
x-ms-traffictypediagnostic: MWHPR1301MB2158:
x-microsoft-antispam-prvs: =?utf-8?q?=3CMWHPR1301MB21588AAC0429EE67EEF02B778?= =?utf-8?q?5E30=40MWHPR1301MB2158=2Enamprd13=2Eprod=2Eoutlook=2Ecom=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0334223192
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810019020=29=284636?= =?utf-8?b?MDA5KSgzNDYwMDIpKDM3NjAwMikoMTM2MDAzKSgzOTg1MDQwMDAwNCkoMzk2?= =?utf-8?b?MDAzKSgzNjYwMDQpKDE5OTAwNCkoMTg5MDAzKSg0Nzg2MDAwMDEpKDMxNjAwMiko?= =?utf-8?q?71200400001=29=28110136005=29=284326008=29=2876116006=29=28650600?= =?utf-8?b?NykoNzY5NjAwNSkoNTQ5MDYwMDMpKDUyNTM2MDE0KSg1MzU0NjAxMSkoNTY2?= =?utf-8?q?0300002=29=288936002=29=2866946007=29=2866476007=29=2864756008=29?= =?utf-8?q?=2866446008=29=2855016002=29=2866556008=29=2886362001=29=28968600?= =?utf-8?b?MykoMjYwMDUpKDQ0ODMyMDExKSgyOTA2MDAyKSg4MTE2NjAwNikoMzM2NTYwMDIp?= =?utf-8?q?=28186003=29=288676002=29=2881156014=29=3B?= DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR1301MB2158; H:MWHPR1301MB2096.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: =?utf-8?q?gSm22y6NaVQwfiLo6MhkP9VM4q83aL/?= =?utf-8?q?WybIcNp3bWX67XhzYXeLFi9shrB1JpGcvlR4exp5S9mNkhZO5KJ6rcWPQtOhcwFs0?= =?utf-8?q?gO46anTOh3BYgmJjinsr2iJur9v9GFK4W/3TieskyWSz/wsJngM7PqhJN2Pf+5L20?= =?utf-8?q?ASWPAGDCiX1gVQkDtGNWuRG7gKu2w5SQw3h0ptRZxyfIvX5loWbz7jMZvx1e60HTC?= =?utf-8?q?BAejJU73uEZKRPjDI/l45S3hAJ0WW8qNr4Y4MHNUw6+uZfP9g6PQqs6tj5lzC1nh9?= =?utf-8?q?n4x+/q4D+lujlKigAbZ9/F1+GPMIZRfbsQKW9zw9m/rTwrvlXMP6OnaoghZnP3u4Y?= =?utf-8?q?HmIHLNeSsh/RrxJ/Ty1L0ZldZFmhft4CXY3t9LniVf1fXdFdT/QvqRZ8cukjPoHun?= =?utf-8?q?AmkhO80OWbcqzFjSIRReuJgxRgUDDzI9DP2gtchwY/g/3/TJlohJKLPcfLmjXIfLj?= =?utf-8?q?84V5SCpZ/2R/3vuFJBmpLUoRRAhvrRU78bSHg6ruDqHduYVA=3D=3D?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?OXRDLcBn5tM8MpVqq0DoVheyseYYbQ?= =?utf-8?q?kJwkwwP71L0S/ht3MTO1KU7QRo4mOuEsVkOLZ4kb824jMP2YYY7r0KxEI+eowWG6U?= =?utf-8?q?BWnPgi29yML8MEoUWC67d7K5W1wgWyFTFcS6mzUIhMGPydLcLq+62sQ=3D=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1c39d897-6df6-4827-098a-08d7c1e987e2
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2020 16:15:04.6533 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: =?utf-8?q?dvBa9CU731nSKkqmRIFh2?= =?utf-8?q?MMxiNuImNtq2j6/tLL4xGIch7PFVo9cuDJ5Ra4PqFtxxaj/P/HtQUuHPnQ7wpwUmQ?= =?utf-8?q?=3D=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1301MB2158
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/8bg3zLvkiWkbfLtrR3m0pVWlVOs>
Subject: Re: [Last-Call] Genart last call review of draft-ietf-ippm-multipoint-alt-mark-06
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Mar 2020 16:15:08 -0000

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@huawei.com> 
Sent: Friday, March 6, 2020 3:51 AM
To: Linda Dunbar <linda.dunbar@futurewei.com>om>; gen-art@ietf.org
Cc: draft-ietf-ippm-multipoint-alt-mark.all@ietf.org; ippm@ietf.org; last-call@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:noreply@ietf.org] 
Sent: Thursday, March 5, 2020 11:20 PM
To: gen-art@ietf.org
Cc: draft-ietf-ippm-multipoint-alt-mark.all@ietf.org; ippm@ietf.org; last-call@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%7Cdeaaf529cb394fe4ed1a08d7c1b3d3ba%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637190850411062631&amp;sdata=uaQYvFu6W40Dj%2Btjq7vKlOhaDSoKfURTFn02DucNe0I%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