Pascal, sorry for the delayed response - was out of the office yesterday and just finishing up an all-morning meeting this AM. I will respond back to you shortly. Fred > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@xxxxxxxxx] > Sent: Tuesday, March 01, 2022 12:43 AM > To: Templin (US), Fred L <Fred.L.Templin@xxxxxxxxxx>; int-dir@xxxxxxxx > Cc: last-call@xxxxxxxx; draft-ietf-ipwave-vehicular-networking.all@xxxxxxxx; its@xxxxxxxx > Subject: [EXTERNAL] RE: [ipwave] Intdir telechat review of draft-ietf-ipwave-vehicular-networking-27 > > EXT email: be mindful of links/attachments. > > > > Hello Fred > > > -----Original Message----- > > From: Templin (US), Fred L <Fred.L.Templin@xxxxxxxxxx> > > Sent: lundi 28 février 2022 19:09 > > To: Pascal Thubert (pthubert) <pthubert@xxxxxxxxx>; int-dir@xxxxxxxx > > Cc: last-call@xxxxxxxx; draft-ietf-ipwave-vehicular- > > networking.all@xxxxxxxx; its@xxxxxxxx > > Subject: RE: [ipwave] Intdir telechat review of draft-ietf-ipwave- > > vehicular-networking-27 > > > > 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? > > > > That would be optimistic. Some of your points are non-technical and Paul is the editor, he should make the decision. > I reacted to the technical points I agreed with to add pressure on Paul to act on them. > Then again I agreed more with the technical issue you raised and your proposed resolution than with your exact wording, and then again > Paul is the editor anyway. > But first and foremost, I see OMNI as an abstract interface for non-broadcast networks, and MLSN as a network that can be reached via > OMNI. I see no opposition but highly complementary stuff. > > > 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. > > If you pick all the addresses of your MANET from the same /64 you have a MLSN. Take RPL: deployed in the smartgrid, it is a MLSN. > Deployed between cars with a mobile network prefix (MNP) each, it's more of a MANET of MNPs. > > Even a hub and spoke like Bluetooth is an MLSN. The idea behind it is to decouple the L3 abstraction from the L2 connectivity and build > select P2P IP links over whatever L2 gives you. For all I can see, this is exactly what you're also describing, and it's not evil, it's a world of > opportunities. In fact, 6LoWPAN explicitly inherits that model from MANET. > > > > 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? > > One or more RSUs can share the same /64. If there's only one RSU per /64 this is a hub and spoke (like a BSS at L2). If multiple RSUs, you > have to route between them for the host addresses in the prefix, (like an ESS will bridge). > > 2 cars, even connected to the same RSU, many not be in sight of one another. So the model is that each car has a P2P IP link with the RSU > and the RSU relays. > > OSPF called that P2MP as opposed to NBMA which was non broadcast full mesh and did not need routing inside. This is where we have to > agree on terms, since you only mention NBMA. > > In a Wi-Fi ESS/BSS, the RSU is an Access point and it does bridging. Outside of the context of a BSS in OCB), all you have is L3 and this is > called a MLSN, and the RSU is a router. So the goal is the exact same as BSS/ESS. Obtain an address that is externally reachable, > topologically correct, and that does not need renumbering as you move within the MLSN. > > > > 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? > > Not related is correct. For global comm, partially correct. You can have multiple MNPs. ULA MNPs are useful for local comms between cars > and relaying in V2V2I, but we also want MNPs that can be globally reachable with NEMO. E.g., a device connected to the Wi-Fi inside the > car (or train) may want to connect to the internet in which case that MNP is GUA. > > More details: > > For V2V, we have a model where the cars have "visitors" MNPs that are ULA and short lived. This helps for anonymizing the MNP owner. > Neighbor vehicles can form addresses from the "visitors" MNP when in range using anonymized IIDs, just like they can from RSUs. This > forms an IP link and you can route along those links, including source routing. This was the original model for RPL. > > Then there's a home MNP that is GUA (and BYOP) for NEMO purpose. And the router address inside that prefix is BYOA if you want to see it > that way. This is for sourcing packets to the internet as opposed to relaying as above. > > Using RPL you can route along the "visitors" MNP between cars to reach the AP of the parking lot, this is how you can do V2V2I. If you inject > that MNP in the RPL then NEMO needs a single tunnel to the parking lot using the parking lot as CoA. If you hide it for privacy reasons, you > need to take your CoA from your own "visitors" MNP, and that's 2 tunnels. OMNI could simplify that. > > We called that MANEMO long ago, coupling MANET for V2V with NEMO for V2I, in order to solve the famous "nested nemo" problem. > > > 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? > > The vehicle is reachable from the internet with that address while in range. As the doc says, this can be short lived, if the vehicle is moving > fast. My car averages < 20mph in practice, and is parked most if its time, so it's useful. > > > 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? > > Having an address that is routable between RSUs is also useful, say along a road. If the RSUs share the same /64 it is still a MLSN, and this > set gives you a scope for the lookups/advertisements. > > Now if the car has a BYOA and you extend your VANET using the RSUs along a road, someone has to define how far the advertisements and > lookups propagate, which is how far this car is reachable from another. That works too, just that the MLSN automates it. > > About BYOA and DAD. There are less random bits in a ULA prefix than in an IID. OTOH there are more random bits in an ULA address since > you randomize both. The question behind is how many randomized bit in the 128 are enough to claim that DAD is not needed. > > > 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? > > > > I'd like to see that. The integration of local and global reachability (ULA vs GUA, MANET vs NEMO) does not appear to be fully solved at this > time. > > Keep safe; > > Pascal > > > > > -----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
