Re: [ippm] Zaheduzzaman Sarker's No Objection on draft-ietf-ippm-rfc8889bis-02: (with COMMENT)

[Giuseppe Fioccola <[e-mail]>]

Hi Zahed,
Thanks for the quick feedback.
Please see my reply inline as [GF]

Regards,

Giuseppe

-----Original Message-----
From: Zaheduzzaman Sarker <[e-mail]> 
Sent: Thursday, July 14, 2022 10:45 AM
To: Giuseppe Fioccola <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: Zaheduzzaman Sarker's No Objection on draft-ietf-ippm-rfc8889bis-02: (with COMMENT)

Hello,

 Thanks for addressing my comments.

See my reflections below prefixed with [ZS]

//Zahed


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

Thanks for working on this specification.

I am supporting Roman, John, Alvaro's discuss.

I have following comments which I believe would improve the document quality, if addressed.

## Section 2: I really didn't get the definition of the flow. May be it is my lack of expertise in English language or the technology used here but when the definition of flow is defined by flow ( is says- a flow can be multipoint-to-multipoint flow) it becomes very difficult to understand. Are we defining flow or identification of flow? It would be great to get a better description of the definition of  "flow". I also agree with John's comment that if a flow does not have traffic, is this also a flow? May be we merely defining the link between network nodes as flow, then I would say the term flow is overloaded.

Actually section 3 has a much better definition of flow. why don't we use that?

       "a flow can be defined by a set of selection rules used to
   match a subset of the packets processed by the network device.  These
   rules specify a set of Layer 3 and Layer 4 header fields
   (identification fields) and the relative values that must be found in
   matching packets"

[GF]: I see your point. To avoid confusion it is better to use only a single definition. I tend to agree that the definition in section 3 is more general and can be used to avoid misunderstanding.

[ZS] great.

## Section 2: according to the definition of the cluster, any single node can be a cluster and measure of the that cluster will be same as point to point measure defined in rfc8321bis (like node packet loss). is that correct interpretation? if yes, rfc8321bis becomes a subset of this specification, is that the intention?

[GF]: Yes it is correct.

[ZS] if this is correct then I wonder what value RFC8321bis brings here, we can just have one RFC to define the mechanism and cover both point to point and multipoint to multipoint. I wonder in the working group has already debated that possibility and decided to go with two different RFCs.

[GF]: It was an option that we considered in the beginning with AD and IPPM before starting with new -bis documents. But, we thought that two separated documents work better for a number of reasons. 
First, point to point case and multipoint to multipoint case are quite different with regards to the methodology of loss and especially delay measurements, so it is better to keep a separated description. A single document would have been too long and complex to read.
In addition, there are a number of implementations and fields of application which only apply the point to point case of RFC8321bis. For reference and compliance reasons the separation is also better.
Another important factor is that the original experimental documents were separated and, for consistency, their elevation to PS can follow the same approach.
Also, RFC8321bis is the foundation of the methodology, but RFC8889bis is not its simple extension to multipoint since it introduces the new concept of clusters and it is worth a dedicated document to explain this approach and related algorithm.
Note that, as discussed with John Scudder, I'm slightly changing the cluster definition to exclude the trivial case of a cluster of a single node so I will also modify the previous text accordingly. The definition will be modified as follows:
Clusters: Smallest identifiable non-trivial subnetwork of the entire monitoring network graph that still satisfies the condition that the number of packets that go in is the same as the number that go out.  A cluster partition algorithm, such as that found in Section 5.1, can be applied to split the monitoring network into clusters.

## Section 2.1 : as group to group segments are not used to define cluster in this specification, I would suggest following change -

       OLD text: the spatial metrics, used for measuring the performance of
       segments of a source to destination path, are applied here to
       group-to-group segments (called clusters).

       NEW text : the spatial metrics, used for measuring the performance of
       segments of a source to destination path, are applied here to
       clusters.

[GF]: Ok.

## Section 4.2 : What is "Non-initial fragments"?

[GF]: This definition is in RFC8321bis and means fragments originated by nodes within the domain. I have to add more explanation here or refer to RFC8321bis

[ZS] reference should work.

[GF]: Ok

## I think it is confusing when terms defined in the terminology section get redefined in the later sections in a different way than how it is defined in the terminology section. the term "cluster" is an example of such case. can we stick to one single definition of cluster and other terms used in this document?

[GF]: Yes, as also raised in other reviews, I think it is better to define cluster only in the Terminology section and refer to it where needed. The same applies to the other terms.

[ZS] right.