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

From: Warren Kumari via Datatracker <[email-masked]>
Date: Tue, 11 Aug 2020 09:10:05 -0700

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.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 11 Aug 2020 19:33:31 +0000

Hi Warren,

Thanks for your review! I see a trend that reviews are mentioning a few similar areas.

replies and proposed resolutions follow,
Al

> -----Original Message-----
> From: Warren Kumari via Datatracker [mailto:[email-masked]]
> Sent: Tuesday, August 11, 2020 12:10 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> Brian Trammell <[email-masked]>; [email-masked]
> Subject: Warren Kumari's Discuss on draft-ietf-ippm-route-09: (with
> DISCUSS and COMMENT)
> 
...
> RFC 2991 describes a number of approaches (e.g Modulo-N Hash, Hash- Threshold,
[acm] 
Yes, I agree with your points, so I re-wrote the whole paragraph and separated into two paragraphs for clarity...

NEW
Internet routing is complex because it depends on the policies of thousands of Autonomous Systems (AS). Most routers perform load balancing on flows using a form of Equal Cost Multiple Path (ECMP). [RFC 2991] describes a number of flow-based or hashed approaches (e.g., Modulo-N Hash, Hash-Threshold, Highest Random Weight (HRW)), and makes some good suggestions. Flow-based ECMP avoids increased the packet delay variation and possibly overwhelming packet reordering in TCP flows

A few routers still divide the workload through packet-based techniques, such as a round-robin scheme to distribute every new outgoing packet to multiple links, as explained in [RFC 2991]. The methods described in this section assume flow-based ECMP.

> real world isn't. Some additional text should solve this...
[acm] 
We have seen some comments on this sentence, let me add your point to the others:

NEW
When considering IPv6 headers, it is necessary to ensure that the IP source and destination addresses and the FlowLabel are constant (but noting that many routers ignore the FlowLabel field at this time), see [RFC6437].

[acm] 
dropping "with IP" here. Clarity and no damage, AFAICT.

> for hybrid active-passive methods of measurement(such as the Hybrid Type I
[acm] 
Yes, tightening this long sentence with two more clear thoughts, as 

NEW
This memo 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] described in [I-D.ietf-ippm-ioam-data]. Methods using [I-D.ietf-ippm-ioam-data] are intended only for single administrative domains that provide a protocol for explicit interrogation of nodes on a path.

> needs clarification or a pointer to later in the document.
[acm] 
You're right, we expanded possibilities at the wrong place without any warning.

NEW
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 which the Node uses when communicating with other Nodes under normal or error conditions.

> I don't think that the "MUST" works here -- I think s/MUST/do/ (or s/MUST//).
[acm] 
Ok, MUST deleted.

>       something, and I think needs to be rewritten or dropped.
[acm] 
Yes, we were a bit too short with this, after the Hop-to-Node terminology conversion:

NEW
Hop Specification	A Hop specification MUST contain a Node Identity, and MAY contain arrival and/or departure interface identification, round trip delay, and an arrival timestamp.

> packets (unrelated to address classes of the past)". 

> I think that it is really
[acm] 
OK, added 
The designator "class C" is used for historical reasons, see [RFC2330].

> it important enough to emphasize). Perhaps "data structure to uniquely identify
[acm] 
More IPPM Framework at work here. A singleton can be thought of as a single measurement.

Added:
... (where *singleton* is part of the IPPM Framework [RFC2330]). 

> like it is a differentiating factor.
[acm] 
The IP address + DNS resolution case is the differentiating case. I'll try to clarify:
NEW
o   If a pair of discovered Nodes identify two different addresses (IP or not), then they will appear to be different Nodes. See item below.

> TCP traceroute is also used when ICMP responses are not received - while
> "such as filtering" *could* cover this, it would require squinting...
[acm] 
Save your vision!  I added:
NEW
UDP and TCP traceroute are also used when ICMP responses are not received.

> implemented in Paris-traceroute/Scamper?
[acm] 
Yes, and other active methods. 
NEW
... (which are visible to active methods).

> understand the Title Case, but please either drop it, or uppercase D in
[acm] 
ok
NEW
Issues with Earlier Work to Define Route Metric
>    path for a particular flow." s/measure RTD/measure the RTD/
[acm] 
ok
NEW
Paris-traceroute allows its users to measure the RTD to every Node of the path for a particular flow.

> 
> 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.
[acm] 
I'm never quite sure what a particular RFC Editor Individual will accept or change. Let's find out.

I executed 1,$ s/ --/ */g   in any case.

[acm] Thanks Warren!
[acm]

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 13 Aug 2020 12:41:32 +0000

Hi Warren and all,

Following many comments and resolutions this week, I am attaching the working version -10 .txt and Diff from -09. Further changes are possible (I made a few clean-up edits today, after addressing Rob's comment).

for the AURA co-authors,
Al

> From: MORTON, ALFRED C (AL)
> Sent: Tuesday, August 11, 2020 3:34 PM
> To: Warren Kumari <[email-masked]>; The IESG <[email-masked]>
> Brian Trammell <[email-masked]>
> Subject: RE: Warren Kumari's Discuss on draft-ietf-ippm-route-09: (with
> DISCUSS and COMMENT)
> 
> *** Security Advisory: This Message Originated Outside of AT&T ***.
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
> 
> Hi Warren,
> 
> Yes, I agree with your points, so I re-wrote the whole paragraph and
> separated into two paragraphs for clarity...
> 
> NEW
> Internet routing is complex because it depends on the policies of
> thousands of Autonomous Systems (AS). Most routers perform load balancing
> on flows using a form of Equal Cost Multiple Path (ECMP). [RFC 2991]
> describes a number of flow-based or hashed approaches (e.g., Modulo-N
> Hash, Hash-Threshold, Highest Random Weight (HRW)), and makes some good
> suggestions. Flow-based ECMP avoids increased the packet delay variation
> and possibly overwhelming packet reordering in TCP flows
> 
> A few routers still divide the workload through packet-based techniques,
> such as a round-robin scheme to distribute every new outgoing packet to
> multiple links, as explained in [RFC 2991]. The methods described in this
> section assume flow-based ECMP.
> 
> 
> >
> When considering IPv6 headers, it is necessary to ensure that the IP
> source and destination addresses and the FlowLabel are constant (but
> noting that many routers ignore the FlowLabel field at this time), see
> [RFC6437].
> 
> >
> >
> This memo 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] described in [I-D.ietf-ippm-ioam-data]. Methods using [I-
> D.ietf-ippm-ioam-data] are intended only for single administrative domains
> that provide a protocol for explicit interrogation of nodes on a path.
> 
> >
> 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 which the Node uses when communicating with other Nodes under
> normal or error conditions.
> 
> >
> Hop Specification	A Hop specification MUST contain a Node Identity,
> and MAY contain arrival and/or departure interface identification, round
> trip delay, and an arrival timestamp.
> 
> >
> o   If a pair of discovered Nodes identify two different addresses (IP or
> not), then they will appear to be different Nodes. See item below.
> 
> 
> >