Pascal, I have no issues with what you said below, and I assume that since you referenced some of my comments you are OK with the rest of the ones that I sent to Paul? I have a discussion point however - the business of multilink subnet. I used to think the concept was inherently evil, but now that I have a deeper understanding of the problem statement I am beginning to see some possibilities. Am I correct that the document assumes that each IP-RSU will be the head-end of a "subnet" consisting of a VANET in which all vehicles configure an address from a common IPv6 prefix? So, for example, IP-RSU1 could be the head-end of a subnet 2001:db8:1:2::/64 and IP-RSU2 could be the head-end of a subnet 2001:db8:3:4::/64 - correct? But, these subnets are not related to the IPv6 MNPs that are on-board the individual vehicles and so would not be used as end system addresses for global-scope comms; correct? So then, what is the purpose of the IP-RSU based multilink subnet? Is it to simply group vehicles according to their current IP-RSU affiliation? Is it to inform the VANET routing protocol to only exchange routing information with other vehicles that share a common IP-RSU based subnet prefix? Or, are there other benefits that I am not understanding? If we see benefits for maintaining IP-RSU based multilink subnets, then we can do that also based on ULA addresses according to the OMNI addressing architecture. The ULAs would then include IP-RSU multilink subnet information in the upper 64 bits and include MNP-based IPv6 global scope addressing information in the lower 64 bits. The OMNI addressing architecture would have to be adapted slightly to make that happen, but before I go there can we have a discussion of the perceived benefits of the IP-RSU based multilink subnet? Thanks in advance for your insights. Fred Templin > -----Original Message----- > From: its [mailto:its-bounces@xxxxxxxx] On Behalf Of Pascal Thubert via Datatracker > Sent: Monday, February 28, 2022 5:57 AM > To: int-dir@xxxxxxxx > Cc: last-call@xxxxxxxx; draft-ietf-ipwave-vehicular-networking.all@xxxxxxxx; its@xxxxxxxx > Subject: [EXTERNAL] [ipwave] Intdir telechat review of draft-ietf-ipwave-vehicular-networking-27 > > EXT email: be mindful of links/attachments. > > > > 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. > > > > _______________________________________________ > its mailing list > its@xxxxxxxx > https://www.ietf.org/mailman/listinfo/its -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
