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

["MORTON, ALFRED C (AL)" <[e-mail]>]

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:[e-mail]]
> Sent: Tuesday, August 11, 2020 12:10 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> Brian Trammell <[e-mail]>; [e-mail]
> Subject: Warren Kumari's Discuss on draft-ietf-ippm-route-09: (with
> DISCUSS and COMMENT)
> 
> Warren Kumari has entered the following ballot position for
> draft-ietf-ippm-route-09: Discuss
> 
...
> 
> ----------------------------------------------------------------------
> 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.
[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.


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

> 
> 
> ----------------------------------------------------------------------
> 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?
[acm] 
dropping "with IP" here. Clarity and no damage, AFAICT.

> 
> 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])."
[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.

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

> 
> 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//).
[acm] 
Ok, MUST deleted.


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

> 
> 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.
[acm] 
OK, added 
The designator "class C" is used for historical reasons, see [RFC2330].

> 
> 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?
[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]). 

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


> 
> 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...
[acm] 
Save your vision!  I added:
NEW
UDP and TCP traceroute are also used when ICMP responses are not received.

> 
> 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?
[acm] 
Yes, and other active methods. 
NEW
... (which are visible to active methods).


> 
> 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.
[acm] 
ok
NEW
Issues with Earlier Work to Define Route Metric
> 
> 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/
[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]