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,
The current version (-19) has already your comments:
https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-29

For your comment on IPv6 SEND to protect against DAD flooding, Chris (my
co-author) and I have tried to address it on the revision.
You can take a look at page 18 in the revision letter.

Could you remove your DISCUSS from the IESG evaluation ballot system?

Thanks.

Best Regards,
Paul



On Sat, Jun 25, 2022 at 4:08 PM Eric Vyncke (evyncke) <[e-mail]>
wrote:

> Paul,
>
>
>
> Sorry for belated reply, your revision letter seems to address all my
> DISCUSS and most of my COMMENTs (still remaining the non-blocking COMMENT
> in section 6.1 about using IPv6 SEND to protect against DAD flooding – non
> blocking so you can safely ignore it).
>
>
>
> As soon as the revised I-D is uploaded with the proposed changes, then I
> am clearing my DISCUSS.
>
>
>
> Regards
>
>
>
> -éric
>
>
>
>
>
> *From: *"Mr. Jaehoon Paul Jeong" <[e-mail]>
> *Date: *Saturday, 25 June 2022 at 04:11
> *To: *Eric Vyncke <[e-mail]>, Roman Danyliw <[e-mail]>
> *Cc: *Lars Eggert <[e-mail]>, Alvaro Retana <[e-mail]>,
> Murray Kucherawy <[e-mail]>, Paul Wouters <
> [e-mail]>, "Rob Wilton (rwilton)" <[e-mail]>,
> Daniel Migault <[e-mail]>, The IESG <[e-mail]>, "
> [e-mail]" <[e-mail]>, skku-iotlab-members <
> [e-mail]>, "Mr. Jaehoon Paul Jeong" <
> [e-mail]>
> *Subject: *Fwd: [ipwave] Éric Vyncke's Discuss on
> draft-ietf-ipwave-vehicular-networking-28: (with DISCUSS and COMMENT)
>
>
>
> Hi Éric and Roman,
>
> Though you guys seem very busy with other stuffs, could you check whether
> my revision is satisfying your DISCUSS or not?
>
>
>
> I hope this IPWAVE PS draft moves forward and IPWAVE WG will be able to
> take the next step.
>
>
>
> Thanks.
>
>
>
> Best Regards,
>
> Paul
>
> ---------- Forwarded message ---------
> From: *Mr. Jaehoon Paul Jeong* <[e-mail]>
> Date: Sat, Jun 11, 2022 at 12:02 AM
> Subject: Re: [ipwave] Éric Vyncke's Discuss on
> draft-ietf-ipwave-vehicular-networking-28: (with DISCUSS and COMMENT)
> To: Éric Vyncke <[e-mail]>, Lars Eggert <[e-mail]>, Roman
> Danyliw <[e-mail]>, Alvaro Retana <[e-mail]>, Murray
> Kucherawy <[e-mail]>, Paul Wouters <[e-mail]>,
> Robert Wilton <[e-mail]>, Daniel Migault <
> [e-mail]>
> Cc: The IESG <[e-mail]>, Pascal Thubert <[e-mail]>, CARLOS
> JESUS BERNARDOS CANO <[e-mail]>, <[e-mail]>, Chris Shen <
> [e-mail]>, skku-iotlab-members <
> [e-mail]>, 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
>
>