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

["Templin (US), Fred L" <[e-mail]>]

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