[ippm] a few notes on draft-ietf-ippm-route-04

["Frank Brockners (fbrockne)" <[e-mail]>]

Just gave draft-ietf-ippm-route-04 a quick read through, as promised during the last IPPM meeting in Prague.
A few general notes:
* Nomenclature: While I understand the objective to extend/update RFC 2330, IMHO we need to adjust some of the terminology in the document to the current use from what was defined back in the 90s. The most problematic IMHO is the term "host".   RFC 2330 defines a "host" as "A computer capable of communicating using the Internet protocols; includes "routers"". But if you consider a more recent document like RFC 8200, there it is stated that a "host" is "any node that is not a router." To grow the confusion, there are sentences like (see lines 179-181) "May contain hosts that do not decrement TTL or Hop Limit, but may have two or more exchange links connecting "discoverable" hosts or routers" which mix "host" and "host or router", despite the fact that host would have been sufficient in this sentence.
One potential resolution could be to evolve to using "nodes" as the superset of end-systems (now typically "hosts") and routers.
And further on this topic: draft-ietf-ippm-route should apply to all types of nodes, including nodes which run in a VM or as a container. Thus the old definition that a host is "a computer" would need to be made more generic in any case. The same applies to the term link which should include virtual links and virtual interfaces (like a vhost interface), ip links to connect namespaces etc.
* Alignment of traceroute-style methods with hybrid methods in the discussion section (3.5). Suggest to harmonize section 3.5 with section 4.2; E.g. statements like "If a discovered host 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." apply well to traceroute-style methods, but might not be true for hybrid methods like IOAM. Similar considerations apply to the next bullet point.
* Updating RFC 5388 (section 3.6): IMHO it would be good to at least get all the requirements for the update spelled out here. Doing the update in an appendix would for sure be a plus but it would even be better if we had an update data model as an IETF YANG model, hence punting the work to a new I-D and just defining the requirements in the current doc is a good solution IMHO.
Editorial notes:
General: consistent spelling for "Hop" (vs "hop").
TTL & HopLimit: In most of the places, TTL & HopLimit are mentioned on par, but there are a few areas where I found it missing. See lines 155, 642, 645, 1035,
line 173: s/This a reality/Parallel paths are a reality/
288: Define Hop first before you set requirements for "hop".
319: Make MP(address) a dedicated definition, e.g. "MP(address) = Measurement Point at address". What does MP actually mean for a host: Arrival on the NIC, arrival at the host stack, arrival at the softswitch, ..?
422: "turs" - not sure what this word means
489: s/In/in/
576: s/FlowLable/FlowLabel/
588: "no options": This reads v4 specific. Luckily the earlier sentence about bytes 20-23 applies to v4 and v6.
623: s/fields of TCP header/fields of the TCP header/
625: s/for UDP case/for the UDP case/
655: choose either "sequence number" or "Sequence Number"
718: Routing class identification: This seems to mostly assume ECMP based on hashing some fields from the packet. Add a discussion about size dependent scheduling methods / flowlet switching?
778: s/anomolous/anomalous/
779: s/dely/delay/
790: s/mesurement/measurement/
791: s/anomolous/anomalous/
816: s/source/encapsulating node/
820: It might be worthwhile to mention that interface identification isn't necessarily limited to IP, i.e. different links in a bundle (LACP) could be identified. Equally well, links without explicit IP addresses can be identified (like with unnumbered interfaces in an IGP deployment).
933: s/develop accurate/develop an accurate/
1019: s/procedure allow us/procedure allows us/
1161: RFC 8403 is published by now
Cheers, Frank