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

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 15 Jul 2019 17:43:45 +0000

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

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 23 Jul 2019 16:13:31 +0000

Hi Frank,  Thanks (again) for your comments!

We've had a hallway conversation on your key points.
I'm putting some of what we talked about on the list,
for more feedback possibilities, in addition to the
IPPM Session on Wednesday.

please see in-line,
Al

From: Frank Brockners (fbrockne) [mailto:[email-masked]]
Sent: Monday, July 15, 2019 1:44 PM
To: [email-masked]; [email-masked]
Subject: a few notes on draft-ietf-ippm-route-04

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.
[acm]
I brought up yet-another-definition when we talked:  Vint Cerf used to joke during his talks (IIRC), A router is a PC with a Graduate student wrapped around it. This supports the RFC2330 host definition, but I also remember cringing a bit when I re-read: "host: A computer..." which was fine when RFC2330 was written, 20 years of development means there are many different types of hosts (baremetal hosts, guest hosts, etc.) and clarification is needed.
Some Options for new path terminology:
A. Retain host, add new Node term and definition:
- RFC 2330 host: a computer capable of IP communication, includes routers
- Node: Any network function on the path capable of IP-layer Communication, includes RFC 2330 hosts
B. Revise host (use the word node in a general way):
- host: a node on the path possessing a coherent compute environment and capable of IP-layer Communication, includes RFC 2330 hosts
C.
 - ?
* 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.
[acm]
Align as much as possible, but also qualify when a limitation applies "only" to the traceroute-type methods (where less info is typically revealed).
* 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.
[acm]
Ok, this is a good collection exercise from the two types of methods, active and hybrid. We go beyond the info that 5388 anticipated collecting, which is a good thing. We definitely punt the YANG model work.
Editorial notes:
[acm]
Thanks for all these catches!
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