Re: [ipwave] Intdir telechat review of draft-ietf-ipwave-vehicular-networking-27

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]> 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:[e-mail]] On Behalf Of Pascal Thubert via Datatracker
>> Sent: Monday, February 28, 2022 5:57 AM
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/its