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

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

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:[e-mail]]
> Sent: Tuesday, March 01, 2022 12:43 AM
> To: Templin (US), Fred L <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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 <[e-mail]>
> > Sent: lundi 28 février 2022 19:09
> > To: Pascal Thubert (pthubert) <[e-mail]>; [e-mail]
> > Cc: [e-mail]; draft-ietf-ipwave-vehicular-
> > [e-mail]; [e-mail]
> > 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:[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