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

["Templin (US), Fred L" <[e-mail]>]

All, I would like to make the following change to the set of comments I submitted
on 2/24/2022:

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

Rather than removing the sentence, I would instead prefer for the document to
make the following revision:

Change: 
"IP tunneling over the wireless link should be avoided for performance efficiency."

To:
"Encapsulation over the wireless link should be minimized for performance efficiency."

I would expect for all of my other comments to be addressed in the next document
version and/or discussed here on the list.

Thank you,

Fred Templin



> -----Original Message-----
> From: its [mailto:[e-mail]] On Behalf Of Templin (US), Fred L
> Sent: Thursday, February 24, 2022 12:51 PM
> To: Erik Kline <[e-mail]>; Pascal Thubert (pthubert) <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-26.txt
> 
> 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."
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its