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

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

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


> -----Original Message-----
> From: MORTON, ALFRED C (AL)
> Sent: Tuesday, August 11, 2020 3:34 PM
> To: Warren Kumari <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> Brian Trammell <[e-mail]>
> 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,
> 
> 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]