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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Hi Éric, Lars, Roman, Alvaro, Murray, Paul, Zaheduzzaman, Robert, Daniel,
Here is the revision of the IPWAVE Problem Statement Draft:
https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-29

I attach a revision letter to explain how Chris and I have addressed
your comments on the revised draft.

If you have further comments or questions, please let me know.

Thanks for your valuable comments and help.

Best Regards,
Paul
--
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department Head
Department of Computer Science and Engineering
Sungkyunkwan University
Office: [phone]
Email: [e-mail], [e-mail]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>


On Wed, Apr 6, 2022 at 3:30 PM Éric Vyncke via Datatracker <[e-mail]>
wrote:

> É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).
>
>
>
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its
>