Reviewer: Pascal Thubert Review result: Ready with Issues 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
