[ipwave] Éric Vyncke's Discuss on draft-ietf-ipwave-vehicular-networking-28: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-ipwave-vehicular-networking-28: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work put into this document. I found the use cases part of
section 3.1 very interesting to read even if some of them seem very far fetched
;-)

Please find below some blocking DISCUSS points (easy to address though), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education), and some nits.

Special thanks to

- Carlos Bernardos for the shepherd's write-up even if a justification for the
informational status would have been welcome but the WG consensus description
is appreciated.

- Pascal Thubert for his IETF last call INT directorate review at:
https://datatracker.ietf.org/doc/review-ietf-ipwave-vehicular-networking-20-intdir-lc-thubert-2021-06-18/
and for his IESG telechat INT directorate review
https://datatracker.ietf.org/doc/review-ietf-ipwave-vehicular-networking-27-intdir-telechat-thubert-2022-02-28/
Pascal's Last Call & telechat reviews were (at least partially) acted upon by
Paul ;-)

I hope that this helps to improve the document,

Regards,

-éric

# DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

## Abstract & Section 1

"then enumerates requirements for the extensions of those IPv6 protocols" does
not match any IPWAVE WG work item, i.e., it is outside the scope of the charter
of IPWAVE WG. As the document does not explicitly specify requirements, I
strongly suggest to use the word "gaps" rather than "requirements" in the
abstract and section 1.

## Section 4.1

Using an IPv6 address out of a ULA prefix still requires DAD. So the text below
should be updated to be corrected:
  "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]."

## Section 4.2

Very similar comment as above (i.e., DAD & MLD must be done for all IPv6
addresses of an interface and not only for the global one):
  "... When global IPv6
   addresses are used, wireless interface configuration and control
   overhead for DAD"

## Section 5.2
  "... If DHCPv6 is used to assign
   a unique IPv6 address to each vehicle in this shared link, DAD is not
   required. "
This is incorrect and must be changed (see section 18.2.10.1. of RFC 8415)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# COMMENTS

"100km/h as the speed limit in highway" will make many European drivers smile
as it is really slow...

## Section 1

"Most countries and regions in the world have adopted the same frequency
allocation for vehicular networks." but there are TWO frequency allocations
described just before, so, which one has been adopted ?

## Section 2

"GPS" is just the USA commercial example of the more generic "global navigation
satellite system" (GNSS), GNSS should be used in this document.

As IP-RSU have at least 2 interfaces, should "Also, it may have *the* third
IP-enabled wireless interface" be replaced by "Also, it may have *a* third
IP-enabled wireless interface" ?

LiDAR ... "by measuring the reflected pulsed light" but on which kind of
metrics ?

## Section 3.1

Should the 1st and 5th bullets be grouped together ?

Please describe "UAM" (e.g., in the terminology section) as it is unclear to
the reader whether it is a crewed / uncrewed aircraft.

If both road and air vehicles are use case, what about river / sea ships or
trains ?

Does the paragraph about "reward system" belong to the use case ? It rather
sounds like a business requirement. Suggest to remove this part.

Like written by Pascal Thubert in his telechat review, the last paragraph
"IPv6-based packet exchange and secure" should be clear that this is not only
about data plane traffic but also control plane L2/L3 ones. Please also use the
Oxford comma, i.e., add a "," after "exchange".

## Section 3.2

Suggest to also mention "5G" after "IP-RSU or 4G-LTE networks"

How is the UAM use case different from a driverless terrestrial EV ? Suggest to
merge those use cases.

## Section 4.1

As noted by other ADs, "Existing network architectures," the list should not
include OMNI yet as it is not deployed and would probably not be described as
an architecture.

"the wireless media interfaces are autoconfigured with a global IPv6 prefix",
is it the same shared prefix or multiple prefixes ?

Is "RSU" the same concept as "IP-RSU" ?

The last paragraph is about TCP session continuity, but does not explain why
multi-path TCP or QUIC session resumption cannot be used.

## Section 4.2

The computation about "dwell time" is interesting even if it is computed in the
best case. But, I really wonder whether using IPv6 and routing are applicable
to the use case as opposed to more layer-2 + tunnel solutions (like 3GPP) with
such short time for hand-over. I am a strong supporter of layer-3 (IPv6 and
routing), but I cannot refrain from thinking that IPv6 is the wrong technical
solution for those use cases... Was this discussed in the WG ?

## Section 5.1

What is "legacy DAD" ?

  "...the NA interval needs to be
   dynamically adjusted according to a vehicle's speed so that the
   vehicle can maintain its neighboring vehicles in a stable way"
With the issues linked to multicast over wireless, are the authors and the WG
sure that increasing the amount of multicast will not aggravate the problem ?
See RFC 9119 (cited as a normative down reference)

## Section 5.1.2

Please add some references to the MADINAS WG current work items. The authors
may also consider adding this use case to the MADINAS use case.

"The pseudonym of a MAC address affects an IPv6 address based on the MAC
address", nearly no implementations use EUI-64 anymore so this part should
probably be removed from the document. But, the change of MAC address probably
has other impact on the IP stack, e.g., the neighbour cache.

## Section 5.1.3

AFAIK, RPL relies on messages to discover the topology and I am afraid that in
such a moving / dynamic environment, there will be too many of RPL messages.
Will RPL scale in this ever changing network ? Please note that I am not a RPL
expert.

## Section 6.1

Some explanations on how SEND protects against DAD flooding would be welcome.

Is "classical IPv6 ND" the same as the previously used "legacy ND" ?

Wondering why "Vehicle Identification Number (VIN)" is suggested to be used as
SubjectAltName in a certificate rather than a car manufacturer cert ?

## Section 6.3

The part about bitcoin and blockchain errs probably too far away from the IETF
remit.

## Appendix B

I fail to understand how RPL and OMNI can be compared as they are vastly
different technologies (routing vs. tunneling).

"In OMNI protocol, each wireless media interface is configured with an IPv6
Unique Local Address (ULA)" but from my last read of OMNI drafts (1+ year ago),
the OMNI virtual interface can have a ULA indeed but the wireless physical ones
are using any prefix.

## Appendix D

What will be the impact of high packet loss rate (that I am expecting on such
networks) on IP parcels ?

# NITS

Please check that all IPv6 addresses are in lowercase (e.g., in section 4.1).