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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 09 Mar 2020 04:17:39 -0700

É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" ?

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

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

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

"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"

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

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 ?

-- 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.

== 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

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

---

From: Giuseppe Fioccola <[email-masked]>
Date: Fri, 13 Mar 2020 15:53:42 +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:[email-masked]] 
Sent: Monday, March 9, 2020 12:18 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Tal Mizrahi <[email-masked]>; [email-masked]
Subject: Éric Vyncke's No Objection on draft-ietf-ippm-multipoint-alt-mark-06: (with COMMENT)

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.)

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.

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.

[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