[ippm] Warren Kumari's Discuss on draft-ietf-ippm-route-09: (with DISCUSS and COMMENT)

[Warren Kumari via Datatracker <[e-mail]>]

Warren Kumari has entered the following ballot position for
draft-ietf-ippm-route-09: Discuss

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-route/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have 2 DISCUSS points. I think that both should be easy to address...

1: "While most of the routers perform load balancing on flows using Equal Cost
Multiple Path (ECMP), a few still divide the workload through packet-based
techniques.  The former scenario is defined according to [RFC2991], while the
latter generates a round-robin scheme to deliver every new outgoing packet. 
ECMP uses a hashing function to ensure that every packet of a flow is delivered
by the same path, and this avoids increasing the packet delay variation and
possibly producing overwhelming packet reordering in TCP flows."

Round-robin / "per packet" is a form ECMP, and RFC2991 doesn't "define" just
the former, it explains both, and recommends the flow based /  hashed approach.
RFC 2991 describes a number of approaches (e.g Modulo-N Hash, Hash-Threshold,
Highest Random Weight (HRW)) and makes some good suggestions, but the text as
written isn't correct.

2: "In IPv6, it is sufficient to be routed identically if the IP source and
destination addresses and the FlowLabel are constant, see [RFC6437]." Many
routers currently ignore the FlowLabel and use other header info, like
port-numbers. The sentence might(?) be true in an idealized network, but in the
real world isn't. Some additional text should solve this...


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

Questions / Comments:
1: "Although primarily intended for hosts communicating on the Internet
   with IP, the definitions and metrics are constructed to be applicable
   to other network domains, if desired."
This above says "with IP", but then the rest implies it works with other things
too - I suggest dropping the "with IP" part, unless this does work with other
protocols?

2: "  Also, to specify a framework for active methods of measurement which
   use the techniques described in [PT] at a minimum, and a framework
   for hybrid active-passive methods of measurement, such as the Hybrid
   Type I method [RFC7799] described in
   [I-D.ietf-ippm-ioam-data](intended only for single administrative
   domains), which do not rely on ICMP and provide a protocol for
   explicit interrogation of nodes on a path."
This is a really long / hard to read sentence - can you split it into multiple?
I had to read it multiple time and am still having a hard time with the nested
clauses. Perhaps: "This also specifies a framework for active methods of
measurement which uses the techniques described in [PT], as well as a framework
for hybrid active-passive methods of measurement(such as the Hybrid Type I
method [RFC7799])."

3: " Node Identity  The unique address for Nodes communicating within the
      network domain.  For Nodes communicating on the Internet with IP,
      it is the globally routable IP address(es) which the Node uses
      when communicating with other Nodes under normal or error
      conditions. "
I'm not sure I understand -- this says the "unique address" and also "IP
address(es)" - it cannot be both singular/unique and multiple. This definition
needs clarification or a pointer to later in the document.

4: "Cooperating Node  Nodes that MUST respond to direct queries for their
      Node identity as part of a previously agreed and established
      interrogation protocol. "
I don't think that the "MUST" works here -- I think s/MUST/do/ (or s/MUST//).

5: "   Hop  A Hop MUST contain a Node Identity, and MAY contain arrival and/
      or departure interface identification, round trip delay, and an
      arrival timestamp." - this definition also doesn't really seem to define
      something, and I think needs to be rewritten or dropped.

6: "Routing Class  A route that treats equally a class C of different  types of
packets (unrelated to address classes of the past)". I think that it is really
unfortunate that the term "class C" was chosen for this - I understand that
there is a clarification, and don't really expect you to change it, but it
needlessly makes the document harder to read for people who naturally associate
Class A, B, C, D with classful addresses. I recognize that this terminology
comes from RFC2330, but it is till confusing. An additional clarification that
this term is being used because of history would probably help.

7: "Next define a *singleton* definition for a Hop on the path, with sufficient
indexes to identify all Hops identified in a measurement interval." I'm not
sure that "singleton" is a well understood term outside of software
engineering, and that you need to better explain it (esp because you have felt
it important enough to emphasize). Perhaps "data structure to uniquely identify
a hop" or similar?

8: "   o  If a pair of discovered Nodes identify two different addresses,
      then they will appear to be different Nodes.

   o  If a pair of discovered Nodes identify two different IP addresses,
      and the IP addresses resolve to the same Node name (in the DNS),
      then they will appear to be the same Nodes."
Please either include "IP" in both or neither of the above, otherwise it sounds
like it is a differentiating factor.

9: " UDP and TCP are used when a particular characteristic needs to
   be verified, such as filtering or traffic shaping on specific ports
   (i.e., services). "
TCP traceroute is also used when ICMP responses are not received - while "such
as filtering" *could* cover this, it would require squinting...

10: "Furthermore, either Paris-traceroute or
   Scamper is capable of unveiling the many available paths between a
   source and destination (which are visible to this method)."
Visible to *which* method? The one described in this doc? The methods
implemented in Paris-traceroute/Scamper?

Nits:

1: "1.1.  Issues with Earlier Work to define Route"
It seems that this is missing a word after "Route" - perhaps metric? Also, I
understand the Title Case, but please either drop it, or uppercase D in define.

2: "Paris-traceroute allows its users to measure RTD in every hop of the
   path for a particular flow."
s/measure RTD/measure the RTD/

3: You seem to be using multiple ways of adding emphasis (*something*, --from
the Observation Point --, etc). This is confusing / doesn't follow existing
style.