Skip to main content

Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring
draft-ietf-ippm-multipoint-alt-mark-09

Yes

(Mirja Kühlewind)

No Objection

(Adam Roach)
(Alissa Cooper)
(Deborah Brungard)
(Suresh Krishnan)

Note: This ballot was opened for revision 06 and is now closed.

Roman Danyliw
No Objection
Comment (2020-03-11 for -07) Sent
I support Ben Kaduk’s DISCUSS position.

** Section 1.  Per “There are some applications of the alternate marking method where there are a lot of monitored flows and nodes.”
-- Editorial.  “alternative marking methods” is lower case but “Alternative Marking methodology” is upper case in other places

-- “a lot of monitored” seems colloquial and imprecise and begged for me, “what’s a lot”? (subsequent text says “n and m are high values”, but I also don’t have a sense for what that might be)

** Section 1.  Per “Without network clustering, it is possible to apply alternate marking only for all the network or per single flow.  Instead, with network    clustering, it is possible to use the network clusters partition …”, the phrase “network clusters partition” doesn’t parse for me.

** Section 4.  Per “By Using the "traditional" alternate marking method only point-to-point paths can be monitored.”, perhaps say alternative marking per RFC8321 instead of “traditional …”.

** Section 4.1.  “In general there are different options: the monitoring network can be obtained by considering all the possible paths for the traffic or also by checking the traffic sometimes and update the graph consequently.”

-- Editorial: s/In general there are different options: … by checking the traffic sometimes and update the graph consequently/In general, there are different options: by periodically checking the traffic and updating the graph as appropriate/

-- Is there any guidance on the how to frequently this evaluation of traffic should be?

** Section 5.  How generalizable is the flow description?  These statements seem inconsistent:

-- Section 4 says “Multipoint Alternate Marking enables the performance measurement for multipoint flows selected by identification fields without any constraints (even the entire network production traffic).  

-- Section 5 says “The flow definition is generalized here, indeed, as described before, a multipoint packet flow is considered and the identification fields of the 5-tuple can be selected without any constraints.

** Section 9.  I didn’t understand what this section was saying that is different than Section 10.  IMO, the “SDN Controller calibrating for performance measurements” and [I-D.song-opsawg-ifit-framework] descriptions seemed like “Examples of applications” covered in Section 10.   The title of this section “An Intelligent Performance Management approach” seemed a little “marketing like”.
Éric Vyncke
No Objection
Comment (2020-03-09 for -06) Sent
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".
Mirja Kühlewind Former IESG member
Yes
Yes (for -06) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2020-03-11 for -07) Sent
(1) Some of the terminology in this document can be confusing.  For example, I can't help but thinking about multicast and replication when reading about a point-to-multipoint flow.  Digging into the document, the concept is eventually explained (and the fact that multicast is not supported).  I think that there would be great benefit in adding a Terminology section to include a short definition of the flow types and other terms (production network, monitoring network, etc.).


(2) This document is classified as Experimental.  What is the experiment?  

Given that the document describes a methodology and not an interoperable implementation, should the experiment be, for example, to consider the applicability of the methodology to different applications?  It can obviously be something else...but I think it is important to indicate what it is.

FWIW, given that this is an "extension of RFC 8321", I think that Experimental is the right status.
Barry Leiba Former IESG member
No Objection
No Objection (2020-03-09 for -07) Sent
I found this to be a somewhat difficult read, with some awkward wording.  Because of time constraints I’ll mostly not comment specifically, but leave it to the RPC.  My comments below on Section 1 are examples.

— Abstract —

   This document aims to generalize and expand this
   methodology

“This document generalizes and expands this methodology”

— Section 1 —
The “; so” in the first sentence doesn’t follow from what comes before.  It seems that you’ve just glued together two unrelated sentences, and I would unglue them: “point-to-point path.  The extension proposed”

How does the extension explain anything?  Isn’t it the document that does the explaining, but then the extension that does the enabling?

I can’t parse the first sentence of the second paragraph, and I can’t figure out what you’re trying to say.  Can you try re-writing it?

Please check to make sure you are consistent about capitalizing “Alternate Marking” and “Multipoint Alternate Marking” through the document.  It looks like you have it about half and half.
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2020-03-19 for -08) Sent for earlier
Thanks for the updates in the -08!
Deborah Brungard Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -07) Not sent