Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-26.txt

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 23 Feb 2022 14:42:24 +0000

Erik, please stand by. I will be posting my change suggestions to the document soon
(today or tomorrow). As we have seen, new draft versions can come through quickly
so please stand by for one that will incorporate my comments.

Thanks - Fred

From: Erik Kline [mailto:[email-masked]]
Sent: Tuesday, February 22, 2022 10:30 PM
To: Templin (US), Fred L <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Pascal Thubert (pthubert) <[email-masked]>
Subject: [EXTERNAL] Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-26.txt

EXT email: be mindful of links/attachments.

I apologize; I see now the diff is small.  I was terribly afraid that the fast-rev'ing version numbers meant lots of text was in flight (as opposed to just being held for fixing small things during incorporation of IESG feedback).

Russ, Carlos,

If you think this document is not ready for the IESG telechat let me know and I'll pull it back so it can get some more rounds of consideration.  For now I'm inclined to let it stay.

Thanks, and apologies,
-Erik

On Tue, Feb 22, 2022 at 10:22 PM Erik Kline <[email-masked]<mailto:[email-masked]>> wrote:
The inclusion of the OMNI stuff was highlihgted during the LC, and I agreed to advance draft 25 to the IESG telechat.

Now I have to re-review draft 27.  I don't know what's changed, but, in general, please avoid major surgery between IETF LC and IESG telechat.  We might need to pull draft 27 back for a 2nd LC.

/me goes to have a look and the diff...

On Tue, Feb 22, 2022 at 7:58 AM Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Doesn’t work, Dirk. Several months ago, Paul took my edits and the document looked
good. Then, someone came in later without my knowing about it and said “take out
all of the AERO/OMNI stuff”, and no one told me about it. This is no longer a balanced
document; this is a document that embraces a particular solution alternative while
ignoring another.

You and I had a testy exchange earlier; if your message is a continuation of that
exchange I can tell you that I do not appreciate it.

Fred

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, February 22, 2022 7:46 AM
To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] AW: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-26.txt

EXT email: be mindful of links/attachments.

Dear Fred, Paul, Russ and all,
From my point of view - only loosely following this discussion - I do agree that Paul has achieved a good balance between different protocols included/mentioned. Thanks for that!

Just a small typo: on page 3 it should also read
‘Automatic Extended Route Optimization (AERO)’ instead of ‘Asymmetric Extended Route Optimization (AERO)’
And maybe one could add on p. 14 the sentence
‘Refer to Appendix A for the description how OMNI can support use of multiple radio technologies in V2X’.

Would that help? What do you think?
Thanks
Best regards
Dirk

Von: its <[email-masked]<mailto:[email-masked]>> Im Auftrag von Templin (US), Fred L
Gesendet: Dienstag, 22. Februar 2022 15:35
An: Mr. Jaehoon Paul Jeong <[email-masked]<mailto:[email-masked]>>; Russ Housley <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Betreff: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-26.txt

The way the document is now, it reads as an endorsement for a particular approach.
The document was good last time I read it (which is a while ago) but I guess someone
got you to make drastic changes without my knowing about it. The document cannot
go forward in its current form.

Fred

From: Mr. Jaehoon Paul Jeong [mailto:[email-masked]]
Sent: Monday, February 21, 2022 7:50 PM
To: Russ Housley <[email-masked]<mailto:[email-masked]>>; Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-26.txt

EXT email: be mindful of links/attachments.

Hi Russ,
I have replied to Fred's email just before.
As the editor, I tried to balance the two approaches even though the text of AERO/OMNI is reduced.

Fred,
I hope you can understand my position as the editor.

Thanks.

Best Regards,
Paul

On Tue, Feb 22, 2022 at 5:26 AM Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:
Paul and Fred:

I think the update is more aligned with the documents that are advancing one the IETF stream.  That said, I would not be apposed to the inclusion of the 6M's, but not in a way that claims that there is only one approach way to address these things.  What do you think about that was a way forward?

Russ

> On Feb 21, 2022, at 2:56 PM, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi, I started reviewing this and found that it has been completely overhauled since I put my
> comments in many months ago. It has in fact been completely rewritten to favor the shared
> IPv6 multilink subnet model over multihop networks, to favor RPL/6LowPan over standard
> MANET routing protocols, to favor IPv6 ND changes over standard IPv6 ND, and to favor
> multilink DAD. None of that is necessary with AERO/OMNI and the NBMA-based virtual link
> created by the OMNI Adaptation. So, I stopped midway through marking up the document
> with my comments because it has taken a complete left turn and started down a wrong path.
>
> What is mainly at the heart of the divergence is that the document now embraces the
> multilink IPv6 subnet model vs the AERO/OMNI NBMA link model that was there the last
> time I looked. But, there is no need for such complication when there is a much simpler
> alternative at hand. I notice also that in the appendices the AERO/OMNI "6M's of Mobile
> Internetworking" was removed - at the very least that needs to be restored.
>
> In its current form, this document has been diverted to go down the wrong path. It
> needs to be either re-balanced or re-written.
>
> Thanks - Fred
>
>> -----Original Message-----
>> From: its [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Templin (US), Fred L
>> Sent: Monday, February 21, 2022 7:28 AM
>> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>> Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-26.txt
>>
>> Hi, it looks like a lot of what was in the draft regarding AERO/OMNI has been cut out
>> so that means I am going to have to re-review it. I will get to this a soon as possible;
>> hopefully in the next couple of days.
>>
>> Fred
>>
>>> -----Original Message-----
>>> From: its [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
>>> Sent: Sunday, February 20, 2022 9:00 PM
>>> To: [email-masked]<mailto:[email-masked]>
>>> Cc: [email-masked]<mailto:[email-masked]>
>>> Subject: [EXTERNAL] [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-26.txt
>>>
>>> EXT email: be mindful of links/attachments.
>>>
>>>
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the IP Wireless Access in Vehicular Environments WG of the IETF.
>>>
>>>        Title           : IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases
>>>        Author          : Jaehoon (Paul) Jeong
>>>     Filename        : draft-ietf-ipwave-vehicular-networking-26.txt
>>>     Pages           : 49
>>>     Date            : 2022-02-20
>>>
>>> Abstract:
>>>   This document discusses the problem statement and use cases of
>>>   IPv6-based vehicular networking for Intelligent Transportation
>>>   Systems (ITS).  The main scenarios of vehicular communications are
>>>   vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and
>>>   vehicle-to-everything (V2X) communications.  First, this document
>>>   explains use cases using V2V, V2I, and V2X networking.  Next, for
>>>   IPv6-based vehicular networks, it makes a gap analysis of current
>>>   IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management,
>>>   and Security & Privacy), and then enumerates requirements for the
>>>   extensions of those IPv6 protocols for IPv6-based vehicular
>>>   networking.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/
>>>
>>> There is also an htmlized version available at:
>>> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-26
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-vehicular-networking-26
>>>
>>>
>>> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>>>
>>>
>>> _______________________________________________
>>> its mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/its
>>
>> _______________________________________________
>> its mailing list
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/its
>
> _______________________________________________
> its mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/its
_______________________________________________
its mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/its

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 24 Feb 2022 20:51:00 +0000

All, see below for my comments on 'draft-ietf-ipwave-vehicular-networking-26.txt'.
It might be worth noting that my colleagues and I have been looking at vehicular
communications use cases for a long time (e.g., see: RANGERS [RFC6139]).

Indeed, support for vehicular communications of all forms (land, sea, air, space)
has long been the driving force behind the AERO and OMNI technologies which
have taken their current shape as a result. Please see below for comments and
make corresponding changes to the document.

Fred Templin

---

Comments on 'draft-ietf-ipwave-vehicular-networking-26.txt':
**************************************************
1) Section 1, change: "Asymmetric Extended Route Optimization (AERO)
[I-D.templin-6man-aero]"
to:
"Automatic Extended Route Optimization based on the Overlay Multilink
Network Interface (AERO/OMNI) [I-D.templin-6man-aero][I-D.templin-6man-omni]".

2) Section 3, change: "The use cases presented in this section serve as
the description and motivation for the need to extend IPv6 and its protocols
to facilitate "Vehicular IPv6"."
to:
"The use cases presented in this section serve as the description and motivation
for the need to augment IPv6 and its protocols to facilitate "Vehicular IPv6"."

3) Section 3.2, change the paragraph beginning: "The existing IPv6 protocol
must be augmented through protocol changes..."
to:
"The existing IPv6 protocol must be augmented either through protocol changes
or by including a new adaptation layer in the architecture that efficiently
maps IPv6 to a diversity of link layer technologies. Augmentation is necessary
to support wireless multihop V2I communications in a highway where RSUs are
sparsely deployed, so a vehicle can reach the wireless coverage of an RSU
through the multihop data forwarding of intermediate vehicles."

4) Section 3.3, change the paragraph beginning: "The existing IPv6 protocol
must be augmented through protocol changes..."
to:
"The existing IPv6 protocol must be augmented through protocol changes or
by including a new adaptation layer in the architecture that efficiently
maps IPv6 to a diversity of underlying link layer technologies. Augmentation
is necessary to support wireless multihop V2X or V2I2X communications in an
urban road network where RSUs are deployed at intersections, so a vehicle
(or a pedestrian's smartphone) can reach the wireless coverage of an RSU
through the multihop data forwarding of intermediate vehicles (or pedestrians'
smartphones) as packet forwarders."

5) Section 4.1, second paragraph, change: "OMNI (Overlay Multilink Network
Interface) [I-D.templin-6man-omni]"
to:
"AERO/OMNI [I-D.templin-6man-aero][I-D.templin-6man-omni]".

6) Section 4.1, third paragraph, change: "Furthermore, the wireless
media interfaces are autoconfigured with a global IPv6 prefix
(e.g., 2001:DB8:1:1::/64) to support both V2V and V2I networking. Note
that 2001:DB8::/32 is a documentation prefix [RFC3849] for example
prefixes in this document, and also that any routable IPv6 address
needs to be routable in a VANET and a vehicular network including IP-RSUs."
to:
"In a first addressing alternative, the wireless media interfaces
are autoconfigured with a global IPv6 prefix (e.g., 2001:DB8:1:1::/64)
to support both V2V and V2I networking. Note that 2001:DB8::/32 is a
documentation prefix [RFC3849] for example prefixes in this document,
and also that any routable IPv6 address needs to be routable in a VANET
and a vehicular network including IP-RSUs. In a second alternative, each
wireless media interface is configured with an IPv6 Unique Local Address
(ULA) [RFC4193] that is assured unique within the vehicular network
according to AERO/OMNI and [RFC5889]. The ULA supports both V2V and V2I
multihop forwarding within the vehicular network (e.g., via a VANET
routing protocol) while each vehicle can communicate with Internet
correspondents using global IPv6 addresses via OMNI interface
encapsulation over the wireless interface."

7) Section 4.1, fifth paragraph, change: "Alternatively, mobile nodes
can employ a "Bring-Your-Own-Addresses (BYOA)" technique using their
own IPv6 Unique Local Addresses (ULAs) [RFC4193] over the wireless
network, which does not require the messaging (e.g., Duplicate Address
Detection (DAD)) of IPv6 Stateless Address Autoconfiguration (SLAAC)
[RFC4862]."
to:
"Alternatively, mobile nodes can configure IPv6 Unique Local Addresses
(ULAs) according AERO/OMNI then support global communications through
OMNI interface encapsulation and forwarding of packets with MNP-based
global IPv6 addresses over the wireless networks. The use of AERO/OMNI
ULA autoconfiguration assures uniqueness such that Duplicate Address
Detection (DAD) of IPv6 Stateless Address Autoconfiguration (SLAAC)
[RFC4862] is not needed."

8) Section 4.2, add the following as a final paragraph:
"In a second alternative when vehicles configure an OMNI interface over
an underlying VANET based on ULA addressing, the global IPv6 addresses
covered by the MNP on-board the vehicle are not injected into the VANET
routing system but instead traverse the VANET in the forwarding plane
via OMNI encapsulation. This allows each vehicle to maintain a constant
and unchanging MNP delegation even as it moves between IP-RSUs. This
avoids any need for vehicle on-board network renumbering due to
mobility and avoids repeated injections and withdrawals of MNP
prefixes within the VANET."

9) Section 4.3, add new paragraph following paragraph beginning
"Figure 3 shows the internetworking" as follows:
"When two vehicles within a ULA-based VANET need to communicate without
the assistance of any infrastructure, they can exchange unencapsulated
IPv6 packets with ULA-based addresses which will be forwarded according
to the VANET routing protocol. Alternatively, the vehicles can use OMNI
interface encapsulation to exchange IPv6 packets with global addresses
taken from their respective MNPs. The encapsulation source and destination
ULAs are algorithmically bound to the IPv6 source and destination global
addresses which allows for stateless encapsulation address determination."

10) Section 4.3, final paragraph, there is no reason to cite as examples
all RFC variants of the OLSR protocol and all extensions of the DLEP
protocol - pick one (or at most 2) RFCs for each. Also, it is important
to state that standard OSPF routing has been optimized to support MANET
applications. Suggested rewrite:
"...which serves MANET routing protocols such as the different versions
of Optimized Link State Routing Protocol (OLSR) [RFC3626][RFC7181], Open
Shortest Path First (OSPF) derivatives (e.g., [RFC5614]) and the Dynamic
Link Exchange Protocol (DLEP) [RFC8175] with its extensions."

11) Section 5.1, second paragraph, change: "they need to be configured
with a link-local IPv6 address or a global IPv6 address"
to:
"they need to be configured with link-local, unique-local and/or global
IPv6 addresses"

12) Section 5.2, third paragraph, change: "An efficient DAD is required
to reduce the overhead of the DAD packets during a vehicle's travel in
a road network"
to:
"DAD is not needed in networks that follow the OMNI ULA autoconfiguration
procedures. In other cases when DAD is needed, it must be made efficient
to reduce the overhead of the DAD packets during a vehicle's travel in
a road network"

13) Section 5.1.1, third paragraph, change: "There is a relationship
between a link and a prefix, besides the different scopes that are
expected from the link-local and global types of IPv6 addresses."
to:
"There is a relationship between a link and a prefix, besides the 
different scopes that are expected from the link-local, unique-local
and global types of IPv6 addresses."

14) Section 5.1.1, add a new second-to-last paragraph as follows:
"Often when two VANETs merge some vehicles may configure addresses from
a first subnet prefix while other vehicles configure addresses from other
subnet prefixes. These merge events must not interfere with the
vehicle-to-vehicle multihop forwarding necessary to support continuous
communications. Additionally, when a vehicle enters the network for the
first time it may need to use a temporary ULA address in initial messages
to negotiate with an IP-RSU for an address within the subnet. The VANET
must therefore provide (short-term) forwarding for vehicles with foreign
addresses, while the subnet prefix serves as an aggregation point of
reference for a particular IP-RSU without impeding multihop forwarding
between vehicles that may belong to different subnets."

15) Section 5.1.3 goes too far in expanding on RPL. It is based on the
claim that: "However, it will be costly to run both vehicular ND and a
vehicular ad hoc routing protocol in terms of control traffic overhead
[RFC9119].". But, the AERO/OMNI approach uses only the MANET routing
protocol control messages at the subnet level then applies unicast-only
IPv6 ND messaging at the OMNI interface level so that there is no traffic
amplification due to multicast IPv6 ND within the subnet. Therefore, a
new third paragraph telling how it works in AERO/OMNI should be added
as follows:
"The AERO/OMNI approach avoids this issue by using MANET routing protocols
only (i.e., and no multicast IPv6 ND messaging) in the wireless network
underlay while applying efficient unicast IPv6 ND messaging in the OMNI
overlay on an as-needed basis for router discovery and NUD. This greatly
reduces the overhead for VANET-wide multicasting while providing agile
accommodation for dynamic topology changes."

Additionally, the RPL text should be reduced by at least 50%.

16) Section 5.2, paragraph 6 change: "Even though the SLAAC with classic
ND costs a DAD during mobility management, the SLAAC with [RFC8505] does
not cost a DAD."
to:
"Even though classic IPv6 ND requires the use of DAD on many link types
during mobility management, address autoconfiguration based on [RFC8505]
and/or AERO/OMNI does not require DAD."

17) Section 5.2, paragraph 6, remove the following text entirely:
"On the other hand, a BYOA does not allow such direct routability
to the Internet since the BYOA is not topologically correct, that is,
not routable in the Internet. In addition, a vehicle configured with
a BYOA needs a tunnel home (e.g., IP-RSU) connected to the Internet,
and the vehicle needs to know which neighboring vehicle is reachable
inside the VANET toward the tunnel home. There is nonnegligible control
overhead to set up and maintain routes to such a tunnel home over
the VANET."

Reason: There is always a cost for maintaining mobility management
for addresses within an MNP. It can be done either by frequent
advertisements/withdrawals of the MNP in the global routing system or
through coordination with a mobility anchor point in an overlay via
encapsulation. The Connexion by Boeing experience showed that dynamic
routing protocol updates do not scale in the global Internet. The
AERO/OMNI services instead minimize routing protocol disturbance
while using efficient mobility signaling in the overlay.

18) Section 5.2, near the end, remove the following sentence: "IP
tunneling over the wireless link should be avoided for performance
efficiency."

Reason: IP tunneling is used only in support of global-scoped IPv6
communication (not local-scoped) and can use effective header
compression for greater efficiency as in AERO/OMNI. In addition,
there is value in using encapsulation both from the standpoint of
minimizing global routing protocol overhead and by accommodating
path MTU diversity (see below).

19) Add a new Section 5.3 as follows:
"5.3 Accommodating MTU Diversity

The wireless and/or wired-line links in paths between both mobile
nodes and fixed network correspondents may configure a variety of
Maximum Transmission Units (MTUs), where all IPv6 links are required
to support a minimum MTU of 1280 octets and MAY support larger MTUs.
Unfortunately, determining the path MTU (i.e., the minimum link MTU
in the path) has proven to be inefficient and unreliable due to the
uncertain nature of the loss-oriented ICMPv6 messaging service used
for path MTU discovery. Recent developments have produced a more
reliable path MTU determination service for TCP [RFC4821] and UDP
[RFC8899] however the MTUs discovered are always limited by the most
restrictive link MTU in the path (often 1500 octets or smaller).

The AERO/OMNI service addresses the MTU issue by introducing a new
layer in the Internet architecture known as the "OMNI Adaptation Layer
(OAL)". The OAL allows end systems that configure an OMNI interface
to utilize a full 65535 octet MTU by leveraging the IPv6 fragmentation
and reassembly service during encapsulation to produce fragment sizes
that are assured of traversing the path without loss due to a
size restriction. (This allows end systems to send packets that are
often much larger than the actual path MTU.)

Performance studies over the course of many decades have proven that
applications will see greater performance by sending smaller numbers
of large packets (as opposed to larger numbers of small packets) even
if fragmentation is needed. The OAL further supports even larger packet
sizes through the IP Parcels construct [I-D.templin-intarea-parcels]
which provides "packet-in-packet" encapsulation for a total size up
to 4MB. Together, the OAL and IP Parcels will provide a revolutionary
new capability for greater efficiency in both mobile and fixed networks."

20) Appendix B, add the following as a final paragraph:
"AERO and OMNI together securely and efficiently address the following
6 M's of Modern Internetworking for mobile V2V, V2I and V2X Clients:

   1.  Multilink: A Client's ability to coordinate multiple diverse
       underlying data links as a single logical unit (i.e., the OMNI
       interface) to achieve the required communications performance and
       reliability objectives.

   2.  Multinet: The ability to span the OMNI link over a segment
       routing topology with multiple diverse administrative domain
       network segments while maintaining seamless E2E communications
       between mobile Clients and correspondents such as air traffic
       controllers and fleet administrators.

   3.  Mobility: A Client's ability to change network points of
       attachment (e.g., moving between wireless base stations) which
       may result in an underlying interface address change without
       disruptions to ongoing communication sessions with peers over the
       OMNI link.

   4.  Multicast: The ability to send a single network transmission that
       reaches multiple Clients belonging to the same interest group
       without disturbing other Clients not subscribed to the interest
       group.

   5.  Multihop: A mobile Client's V2V relaying capability useful when
       multiple forwarding hops between vehicles may be necessary to
       reach back to an infrastructure access point connection to the
       OMNI link.

   6.  MTU Assurance: The ability to deliver packets of various robust
       sizes between peers without loss due to a link size restriction,
       and to dynamically adjust packet sizes in order to achieve the
       optimal performance for each independent traffic flow."

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 25 Feb 2022 08:55:25 +0900

Hi Fred,
Thanks for your suggested update.

However, I need the review from Pascal as an INTDIR reviewer.

Pascal,
Could you review the update from Fred and confirm that his update does not
break the balance between the two approaches of RPL and AERO/ONMI?

Thanks.

Best Regards,
Paul

2022년 2월 25일 (금) 오전 5:51, Templin (US), Fred L <[email-masked]>님이
작성:

> All, see below for my comments on
> 'draft-ietf-ipwave-vehicular-networking-26.txt'.
> Network Interface (AERO/OMNI)
> [I-D.templin-6man-aero][I-D.templin-6man-omni]".
>
-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department Head
Department of Computer Science and Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: Erik Kline <[email-masked]>
Date: Thu, 24 Feb 2022 15:59:23 -0800

Fred,

I cannot find (via some light Google searching) any reference to an
industry standard understanding of these "6 Ms".  If we're going to set
down Principles of Networking like this I wonder if we should try to get
more review or maybe look for some academic citation even.

If there is existing literature on this I'd be interested to read it.

Thanks,
-Erik