Skip to main content

Telechat Review of draft-ietf-ipwave-vehicular-networking-27
review-ietf-ipwave-vehicular-networking-27-intdir-telechat-thubert-2022-02-28-00

Request Review of draft-ietf-ipwave-vehicular-networking
Requested revision No specific revision (document currently at 30)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2022-03-30
Requested 2022-02-09
Requested by Éric Vyncke
Authors Jaehoon Paul Jeong
I-D last updated 2022-02-28
Completed reviews Intdir Last Call review of -20 by Pascal Thubert (diff)
Artart Telechat review of -27 by Jim Fenton (diff)
Intdir Telechat review of -27 by Pascal Thubert (diff)
Secdir Telechat review of -27 by Daniel Migault (diff)
Secdir Telechat review of -28 by Daniel Migault (diff)
Comments
As the document had 4 revisions from the Last Call review by Pascal Thubert, a 2nd intdir review would be very useful. The review can be done by Pascal again or by another reviewer with IPv6 and/or mobility background.

Thank you

-éric
Assignment Reviewer Pascal Thubert
State Completed
Request Telechat review on draft-ietf-ipwave-vehicular-networking by Internet Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/Mlh8RDcRN8igNCgFeFEZBY6dKa0
Reviewed revision 27 (document currently at 30)
Result Ready w/issues
Completed 2022-02-28
review-ietf-ipwave-vehicular-networking-27-intdir-telechat-thubert-2022-02-28-00
I am an assigned INT directorate reviewer for
draft-ietf-ipwave-vehicular-networking-27. These comments were written
primarily for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments
from any other IETF contributors and resolve them along with any other Last
Call comments that have been received. For more details on the INT Directorate,
see https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

Based on my review, the document IS ready to go to IETF Last Call and therefore
CAN be forwarded to the IESG.

I find the document well written, well referenced, and very informative. It
fits the general goal of use-cases and problem statement publication.

The following are other issues I found with this document that SHOULD be
corrected before publication:

Fig 1 and section 4.1 show a “Corresponding Node”. Not sure where the term
comes from, in NMIP and NEMO it is “Correspondent Node”  see and refer to RFC
4885.

About
Section 3.1: “
   To support applications of these V2I use cases, the required
   functions of IPv6 include IPv6-based packet exchange, transport-layer
   session continuity, and secure, safe communication between a vehicle
   and an infrastructure node (e.g., IP-RSU) in the vehicular network.

“
Section 3.2: “   To support applications of these V2I use cases, the required
   functions of IPv6 include IPv6-based packet exchange, transport-layer
   session continuity, and secure, safe communication between a vehicle
   and an infrastructure node (e.g., IP-RSU) in the vehicular network.
”
Section 3.3:
“
   To support applications of these V2X use cases, the required
   functions of IPv6 include IPv6-based packet exchange, transport-layer
   session continuity, and secure, safe communication between a vehicle
   and a pedestrian either directly or indirectly via an IP-RSU.

“
Each time, the text could clarify what goes in “packet exchange” since as
written that seems to refer to data plane while the problem for IP is mostly
control plane. e.g., the problem of discovering adjacent peers (addresses,
networks) should be listed there shouldn’t it? Addressing is an topic of
interest as well (BYO Address/Prefix vs. obtain a local address, how that
relates with DAD and global connectivity). The doc discusses that heavily
(around 5.1) and then there’s the discussion in 4.3 on ND variations and
(MANET) NHDP, that must happen before IPv6 packets can be exchanged.

As a hint, a suggestion can be:
“
… functions of IPv6 include IPv6 communication enablement with neighborhood
discovery and IPv6 address management, reachability with adapted network models
and routing methods, transport-layer … “

Section 3.2

Fred said ‘
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."
‘

I agree that the document omits V2V2I completely. This is true in Fred’s
highway case, but true also in a simple parking lot to share Wi-Fi access when
the AP is too far. In the MIPv6 family we called that nested NEMO. The problem
statement of nested NEMO is RFC 4888. I believe you need to provide a minimum
of hint that V2V2I exists and for the lack of more reference you can search
“nested NEMO”.

Note that the early RPL was a solution for nested NEMO and interworked with
NEMO. It has been tested successfully by NASA at their Glenn Center but I do
not think something was published at the time, so no ref.

Note that I also agree with Fred’s point on 3.3. Maybe you can make it more
verbose but in each case there’s a need to indicate that V2A2B can exist and
needs future attention, even if it is a harder problem.


Section 4.1:
“
In
   this case, a handover for Vehicle2 needs to be performed by either a
   host-based mobility management scheme (e.g., MIPv6 [RFC6275] …
…
“
Section 4.2:

“
  Existing network architectures, such as the network architectures of
   PMIPv6 [RFC5213] …
“

I see you have a reference to NEMO in the introduction, but this is where the
reference makes the most sense and it is missing, next to PMIPv6.

It is easy to confuse network-based mobility (which is PMIPv6 vs. MIPv6, and is
MIPv4 anyway) and network mobility, which is the case of a car that has a /64
inside and has to handle mobility for the /64.

Indeed NEMO is the MIPv6 for networks (a mobile prefix inside the car vs.
MIP/PMIP which is a host address moving) and vehicles where a main use case for
it. PMIPv6 is a variation of MIPv6 that distributes the roles differently for
the lack of support by end devices, but does not route for a mobile prefix.
Network-based does not mean “mobile network”, and then you often call the
mobile network a moving network, again per RFC 4885.

For the latter, please stick to IETF terminology of “mobile network” as in RFC
3963, that will help the reader. I suggest you reference RFC 3963 here, and add
RFC 4888 for completeness.

Section 4.1:

“
  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].
“
Again listing Bring your own prefix a well as address would improve
completeness. A typical car has a mobile prefix inside.

Section 4.2:

“
OMNI can support the
“

Suggest “OMNI is designed to support” unless there’s an actual reference?

Section 4.3
Fred says “
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."

“
I agree. Maybe mention that there are V2V use case with a fixed set of cars
(platooning) and others with variable neighborhood (parking lot, on the road),
and the optimum solution may vary.

Section 5:

“is 72 seconds” looks precise though in fact it is very rough. Could say “in
the order of a minute”. Same for V2V, 36s.

Section 5.1.1

“off-link”

That terminology does not really exist. All we have is “not-onlink”.

Section 5.2

“There is nonnegligible
   control overhead to set up and maintain routes to such a tunnel home
   over the VANET.”

There again a link to RFC 4888

“Vehicles can use the TCC as their Home Network having a home agent
   for mobility management as in MIPv6 [RFC6275] and PMIPv6 [RFC5213],”

add “and NEMO [RFC 3963]”

Appendix A: Mentions OMNI but fails to document real world implemented
protocols such as DLEP which abstract the radio modem over ethernet

The following are minor issues (typos, misspelling, minor text improvements)
with the document:

Section 5.1:
“
   This merging and partitioning should be considered for the
   IPv6 ND such as IPv6 Stateless Address Autoconfiguration (SLAAC)
   [RFC4862].
“
“
they may not communicate with each other not in one
   hop in the same

“
I can understand but the language seems incorrect. Also Fred says:
‘
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"

‘
I mostly agree but then, those addresses are not necessarily configured. Maybe
just says that they need the addresses.

Section 6.1

“the DAD”: we usually do not have the “the”. This appears throughout.