Re: [ippm] Éric Vyncke's No Objection on draft-ietf-ippm-multipoint-alt-mark-06: (with COMMENT)

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Fri, 13 March 2020 15:53 UTC

Return-Path: <giuseppe.fioccola@huawei.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD113A0D49; Fri, 13 Mar 2020 08:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Vehb8G4UKzc6; Fri, 13 Mar 2020 08:53:48 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 65E0C3A0D3F; Fri, 13 Mar 2020 08:53:48 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id CA2AC9F0470BE594AE36; Fri, 13 Mar 2020 15:53:43 +0000 (GMT)
Received: from fraeml721-chm.china.huawei.com (10.206.15.17) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 13 Mar 2020 15:53:43 +0000
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml721-chm.china.huawei.com (10.206.15.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 13 Mar 2020 16:53:43 +0100
Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.1713.004; Fri, 13 Mar 2020 16:53:42 +0100
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Éric Vyncke <evyncke@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-ippm-multipoint-alt-mark@ietf.org" <draft-ietf-ippm-multipoint-alt-mark@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Thread-Topic: Éric Vyncke's No Objection on draft-ietf-ippm-multipoint-alt-mark-06: (with COMMENT)
Thread-Index: AQHV9gRdDhBpUBabm02GzS3FCPiep6hGq6sg
Date: Fri, 13 Mar 2020 15:53:42 +0000
Message-ID: <66a720d267df48f6a1f5f389ef9a4f18@huawei.com>
References: <158375265948.13761.4352578642816303499@ietfa.amsl.com>
In-Reply-To: <158375265948.13761.4352578642816303499@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.5.205]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/p-ouVUlQVl8HWOZZzc1nbbix400>
Subject: Re: [ippm] Éric Vyncke's No Objection on draft-ietf-ippm-multipoint-alt-mark-06: (with COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Mar 2020 15:53:50 -0000

Dear Eric,
Thanks for your comment.
Please find my answers inline tagged as [GF].
I will include the proposed changes in the next version.
In particular, please let me know your opinion in relation to my reply on your very first point.

Best Regards,

Giuseppe

-----Original Message-----
From: Éric Vyncke via Datatracker [mailto:noreply@ietf.org] 
Sent: Monday, March 9, 2020 12:18 PM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ippm-multipoint-alt-mark@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org; Tal Mizrahi <tal.mizrahi.phd@gmail.com>; tal.mizrahi.phd@gmail.com
Subject: Éric Vyncke's No Objection on draft-ietf-ippm-multipoint-alt-mark-06: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-ippm-multipoint-alt-mark-06: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-multipoint-alt-mark/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. Beside some of my COMMENT about the wording, the flow and the explanations make the document easy to read.

Please find below some non-blocking COMMENTs and NITs. An answer will be appreciated.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

The wording "Multipoint to multipoint" raised confusion in my mind to be honest. It took reading further in the document to understand what it was about. What about: "multi-party multiple flows" or "aggregated alternate marking" or "clustered alternate marking" ?

[GF]: We can evaluate a change. Maybe "clustered alternate marking". Are you suggesting to replace "Multipoint Alternate Marking" with "Clustered Alternate Marking" in the title and within the entire document?

-- Section 1 --
In the 5th paragraph, suggest to replace "Multipoint alternate marking" by "this document" (if my assumption is correct).

[GF]: Ok, correct.

" Intelligent Network " looks more like a marketing name than an IETF defined one.

[GF]: We can change "Intelligent" with "reflection-loop" or "closed-loop".

-- Section 3 --
What's in a name... but using "flow" to convey the semantics of multiple flows is weird. Why not using "aggregated flows" ?

[GF]: Yes, I will change it.

"headers fields" is it limited to layer-3 only? Probably worth specifying so early in the text by "layer-3 and layer-4 headers fields"

[GF]: I can extend the definition here.

Using "TCP 5-tuple" looks simple but what about fragmented packets ?

[GF]: We mentioned the TCP 5-tuple just to make an example of flow identification but we want to generalize the concept in this document. Maybe we can mention that fragmented packets case can be managed with this methodology if fragmentation happens outside the portion of the monitored network. 

I really have problems with sentences such as "ECMP flow is in scope by definition, since it is a point-to-multipoint unicast flow", esp "point-to-multipoint unicast flow" that looks like an oxymoron to me. Perhaps, it is only me having this parsing problem ?

[GF]: I know, but it is just to distinguish it from the multicast case that is not in scope here. If we say only "point-to-multipoint flow" someone can get confused.

-- Section 4 --
Again about IPv4 fragmentation, if fragmentation happens on the path, then there could be more IP packets received than sent. Or are non-initial fragments ignored? If so, I suggest to clarify the text.

[GF]: I will specify within the text that non-initial fragments are not considered here.

== NITS ==

RFC 7322 suggests "The full expansion of the text should be followed by the abbreviation itself in parentheses" ;-) Not always applied through this
document: e.g., CIR, OTT

[GF]: Agree, I will include the full expansion of the text.

-- Section 1 --
s/ECMP (Equal-Cost Multi-Path) paths/ECMP (Equal-Cost MultiPath)/ to avoid repeating "path".

[GF]: Ok