Advanced Unidirectional Route Assessment (AURA)
RFC 9198
Yes
Martin Duke
No Objection
(Alissa Cooper)
(Alvaro Retana)
(Barry Leiba)
(Deborah Brungard)
Note: This ballot was opened for revision 09 and is now closed.
Martin Duke
Yes
Erik Kline
(was Discuss)
No Objection
Comment
(2020-08-11 for -09)
Sent for earlier
Clearing Discuss based on feedback about changes to the working copy.
Murray Kucherawy
No Objection
Comment
(2020-08-11 for -09)
Sent
Section 3's title made me expect a glossary, but it also lays out actual normative requirements. This seems odd. Personal preference, but I suggest separating them out. I note that Warren also tripped over this. Also in Section 3, I tripped over "class C" as Warren did. But I think what you're doing is trying to introduce a label "C" to define the class of packet types in this context, so maybe: OLD: A route that treats equally a class C of different ... NEW: A route that treats equally a class, referred to here as "C", of different ... Then you can just refer to "C" later and drop the confusing references to "class C". Section 3.1 starts with something that isn't a sentence. I suggest making it one. Section 4.1 uses SHOULD in a number of places that leave me wondering, "Or else what?" You're presenting the implementer with a choice here, but it doesn't feel like these choices are fully developed. The same occurs in 4.3. Are nodes not conforming to these SHOULDs malfunctioning, misconfigured, or simply opting out?
Robert Wilton
No Objection
Comment
(2020-08-13 for -09)
Sent
Hi, Thank you for this document, I found it mostly straight forward to read, but I find the definition in section 3.2 slightly confusing. 3.2. Parameters This section lists the REQUIRED input factors to specify a Route metric. ... Possibly I'm slightly confused by what a Route metric is (it is outside of domain of knowledge) but I was surprised by some of the input parameters (e.g. "i", "T", "Ta"). This is probably because I initially read this sentence as defining what parameters would need to be specified to enable an program to perform a route metric calculation across the network (e.g., like the set of options that might be provided to traceroute). However, I suspect a different meaning is intended, perhaps that these are the mandatory parameters that must be considered in a route metric calculation? Perhaps some tweaking of this text might help clarify the intent? Regards, Rob
Roman Danyliw
No Objection
Comment
(2020-08-12 for -09)
Not sent
Thanks for the document. All my feedback is already captured by my peer ADs.
Warren Kumari
(was Discuss)
No Objection
Comment
(2020-08-20)
Sent
Thank you for addressing my DISCUSS. 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.
Éric Vyncke
No Objection
Comment
(2020-08-12 for -09)
Sent
Thank you for the work put into this document. I support many of the previous COMMENT / DISCUSS points raised by Warren and Erik. I will avoid repeating other ADs' points. Please find below a couple of non-blocking COMMENTs (and I would appreciate a reply to each of my COMMENTs). I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 1.1 -- "path detection methods like [PT] rely on TTL limits", please add the name rather than a reference to [PT] (I assume it is Paris Traceroute). Also, I suggest to s/TTL/hop limit/ (or use the same verbiage as for "cloud subpath". Please fix "that decrement TTL or Hop Count" into "hop limit" ;-) -- Section 3.5 -- About bullet 3, "If a discovered Node always replies using the same network address, regardless of the interface a packet arrives on, then multiple parallel links cannot be detected in that network domain." If RFC 5837 is implemented, then in this case parallel links can still be detected based on the discovery mechanism or did I miss anything ? -- Section 4.1 -- "[SCAMPER] supports IPv6 traceroute measurements, keeping the FlowLabel constant in all packets." All packets of the same flow or among all flows ? (I guess from the same measurement but probably worth adding more description). The way the sentence is worded sounds like 'only scamper can do IPv6 traceroutes. As noted in other IESG reviews, I would appreciate clarification / fixes in "it is sufficient to be routed identically if the IP source and destination addresses and the FlowLabel are constant" and the following list About IPv6, I fear that the presence of some extension headers may prevent the hashing in ECMP/UCMP. Should there be some text around this issue ? Other reviews have raise a DISCUSS about "The IP identification field." that does not exist in IPv6, so, I won't raise it again. -- Section 6 -- This section is written by using only IPv4 vocabulary while other sections are also mentioning IPv6 concepts. == NITS == https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-ippm-route-09.txt points to a couple of downrefs. ECMP and UCMP are expanded multiple times.
Alissa Cooper Former IESG member
No Objection
No Objection
(for -09)
Not sent
Alvaro Retana Former IESG member
No Objection
No Objection
(for -09)
Not sent
Barry Leiba Former IESG member
No Objection
No Objection
(for -09)
Not sent
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2020-08-07 for -09)
Sent
Section 1 test. However, metrics for assessment of path components and related performance aspects had not been attempted in IPPM when the [RFC2330] framework was written. nit(?): this seems to be the only place in the document that uses the phrase "path component", and it was a bit confusing to me. That is, I'm used to seeing "path component" being (e.g.) one hop or link in a multi-link path from source to destination, but the context here suggests that it might be referring to something more like a single route within a route ensemble. I don't have a specific proposed change; I just wanted to mention that I puzzled over this wording for a bit. Section 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. [...] nit: could you remind us that the "Also" refers to the scope of this work (the previous paragraph started with "The scope is" but there was a fair bit of intervening stuff between there and here). Hop A Hop MUST contain a Node Identity, and MAY contain arrival and/ or departure interface identification, round trip delay, and an arrival timestamp. In my head a "hop" is the operation of going from node A to node B, i.e., the journey and not the destination. So if we're associating a node identity with the hop, would we need to say if that's the source or destination node of the "hop" (or am I just misunderstanding things)? Section 3.3 Nmax, the largest value of i needed for a packet to be received at Dst (sent between T0 and Tf). Nmax may be equal to N. I'm not really sure I understand how Nmax works. That is, for any given packet, it has a value for 'i', and that packet may or may not be delivered. But with 'i' defined as the limit on the number of hops for "a specific packet may visit", I don't see how we get to do multiple tries for the same packet with different 'i', as we would need to do in order to determine the "largest value of i *needed*" (emphasis mine). That is, we can set 'i' unreasonably large and that would result in delivery, but that does not (as I understand it) meet the definition for Nmax -- Nmax is supposed to be a boundary value for some condition. I'm just not entirely clear on exactly what that boundary is, since we're talking about a specific packet, and my understanding is that we only get one crack at a specific packet. o t(i,j) Arrival Timestamp (where t(i,j) is ideally supplied by the Hop, or approximated from the sending time of the packet that revealed the Hop) I'm getting a bit of deja vu as I write this, but it seems risky to propose using the term "arrival timestamp" both for something generated at the Hop and something generated by the sender of the packet, since that loses information about the accuracy of the value for a given use case. Perhaps it's best to reserve the term for the ideal quantity and leave approximations for the processing pipeline (as opposed to the measurement pipeline). Section 3.4 RTL(i,j,T) is defined as a singleton of the [RFC6673] Round-trip Loss between the Node with address = Src and the Node at Hop h(i,j) at time T. Just to check my understanding: does the "singleton" and "at time T" force us into a logical (boolean) loss metric for this case, as opposed to a sample-ratio-type loss metric? Section 3.6 identities at a minimum. The models need to be expanded to include these features, as well as Arrival Interface ID, Departure Interface ID, and Arrival Timestamp, when available. [...] Is this expected to occur as future work? (Is there an I-D worth referencing?) Section 4.1 Internet routing is complex because it depends on the policies of thousands of Autonomous Systems (AS). 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. [...] I was surprised to see "packet-based techniques" refer to a round-robin scheme for queuing outgoing packets across interfaces, but assume this just means I need to do more background reading. Any tips for where to start? Formally, to maintain the same flow in the measurements to a particular hop, the Type-P-Route-Ensemble-Method-Variant packets should be[PT]: It's not entirely clear that we need a reference for these attributes; they seem to be fairly easy to verify independently, IIUC. o TCP case: For IPv4, the fields Src, Dst, port-Src, port_Dst, sequence number, and Diffserv Field SHOULD be the same. For IPv6, the field FlowLabel, Src and Dst SHOULD be the same. Are we happy to pair "to maintain the same flow" (previous paragraph) with "SHOULD be the same" (here, and subsequent bullet points)? Section 4.1 1. SHOULD occasionally check path portions which have exhibited stable results over time, particularly ingress and egress portions of the path. Do we want to give any (e.g., order of magnitude) guidance for "occasionally"? Section 4.2 In addition to node identity, nodes may also identify the ingress and egress interfaces utilized by the tracing packet, the time of day when the packet was processed, and other generic data (as described nit: I'd consider "absolute time" over "time of day", since the latter may have connotations of implying that there is 24-hour-periodic behavior. (It may also be subject to local time zone on the node inserting the value.) Section 4.3 1. Nodes at the ingress to the domain SHOULD be both Discoverable and Cooperating, and SHOULD reveal the same Node Identity in response to both active and hybrid methods. The second clause here seems redundant with point (2) that follows. (Similarly for point (3)'s similar clause.) That is, the recommendation to use the same identity for both methods can only ever apply when the node in question is both Discoverable and Cooperating -- if it's only one, then there will only be one identity available, and no need for consistency across methods. When Nodes follow these requirements, it becomes a simple matter to Perhaps a philosophical question, but are "SHOULD"-level directives more of "requirements" or "guidelines"? Section 5 traffic load is not stationary. Nonetheless, as the first approach, a link seems to be congested if, after sending several traceroute probes, it is possible to detect congestion observing different statistics parameters (e.g., see [IDCong]). Finally, to recognize nit: please check the wording of this sentence; I think there may be a missing word or similar. Section 6 every hop. This procedure could be done for a single Member Route flow, with parameter E set as False, or for every detected Route Ensemble flow (E=True). nit: I don't think we define 'E' until the full procedure, a few paragraphs below. made. Line 8 and 13 set a timer for each cycle of measurements. A cycle comprises the traceroutes packets, considering every possible Hop and the alternatives paths in the Alt variable (ensured in lines 9-12). [...] I recognize that this is pseudocode, but "what if the advanced-traceroute() operation takes longer than the i_t time?" Section 7 We could consider some bland statement about the measurement technologies (e.g., ICMP) not providing cryptographic protection for the requested/returned data, and the risks of processing untrusted data in general. This is particularly true for reverse DNS data, used in determining whether node identities represent the same node or not, since DNSSEC deployment remains inconsistent (especially for the reverse zone). The security considerations that apply to any active measurement of live paths are relevant here as well. See [RFC4656] and [RFC5357]. (The security considerations of 5357 don't seem to be adding much discussion, here, though I don't object to referencing it.) Section 9 Should we intuitively know who the "original 3 authors" are? Section 11.1 I was surprised to see draft-ietf-ippm-ioam-data in the normative references section, as all the previous discussion was consistent with merely an informative reference. Similarly, RFCs 5388, 5835, 6437, and 7312 do not seem to be referenced in a fashion that requires a normative reference.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -09)
Not sent