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, Roman, Lars, Alvaro, Murray, Paul, Robert, and Daniel,
Let me remind you of the revision of the IPWAVE Problem Statement Draft:
https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-29

Zahed gave me his comment, and I will reflect it on version -30.

Could you review my revision on your comments and update your position as
soon as possible?

Thanks for your valuable comments and help.

Best Regards,
Paul

On Fri, May 20, 2022 at 4:31 AM Mr. Jaehoon Paul Jeong <
[e-mail]> wrote:

> 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
>>
>