Re: [ipwave] copy of my review of draft-ietf-ipwave-vehicular-networking-27

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

Hi Pascal,
You are right.

I will reflect your last comment about IPv6 ND on the next revision.

Thanks.

Best Regards,
Paul

2022년 4월 1일 (금) 오후 6:59, Pascal Thubert (pthubert) <[e-mail]>님이
작성:

> Many thanks Paul and authors for addressing my comments as well as the
> ones from Fred.
>
>
>
> I’m good with those changes.
>
>
>
> I note that one suggested change did not happen, about :
>
> “
>
>    This merging and partitioning should be considered for the
>
>    IPv6 ND such as IPv6 Stateless Address Autoconfiguration (SLAAC)
>
>    [RFC4862 <https://datatracker.ietf.org/doc/html/rfc4862>].
>
>
>
> “
>
>
>
> I think you mean that SLAAC is not compatible with merging and
> partitioning, and that additional work is needed for ND to operate properly
> under those circumstances.
>
> If I’m correct, please express it. Maybe also use a ref to
> draft-nordmark-intarea-ippl ?
>
>
>
> Otherwise all good!
>
>
>
> Keep safe;
>
>
>
> Pascal
>
>
>
>
>
>
>
>
>
> *From:* Mr. Jaehoon Paul Jeong <[e-mail]>
> *Sent:* mercredi 30 mars 2022 18:45
> *To:* Pascal Thubert (pthubert) <[e-mail]>
> *Cc:* Erik Kline ([e-mail]) <[e-mail]>; Templin (US), Fred L <
> [e-mail]>; [e-mail]; [e-mail]; Chris Shen <
> [e-mail]>; skku-iotlab-members <
> [e-mail]>; Mr. Jaehoon Paul Jeong <
> [e-mail]>
> *Subject:* Re: copy of my review of
> draft-ietf-ipwave-vehicular-networking-27
>
>
>
> Hi Pascal,
>
>
> Here is the revision of IPWAVE PS Draft:
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-28
>
> I attach a revision letter to explain how Chris and I have addressed your
> comments
>
> on the revision.
>
> Thanks.
>
> Best Regards,
> Paul
>
>
>
>
>
> On Mon, Feb 28, 2022 at 10:58 PM Pascal Thubert (pthubert) <
> [e-mail]> wrote:
>
>
>
> 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.
>
>
>
>
>
> Voila!
>
>
>
> Pascal
>
> --
===========================
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>