Fred, it will be hard on email but what kills me is that we’re probably 95% in agreement. And the 5 left can probably be resolved with a white board… Please give me time to answer it’s late here and I m well done… Regards, Pascal > Le 28 févr. 2022 à 19:09, Templin (US), Fred L <Fred.L.Templin@xxxxxxxxxx> a écrit : > > 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
