Subject: Re: [ipwave] Intdir last call review of draft-ietf-ipwave-vehicular-networking-20

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Wed, 1 Sep 2021 20:49:03 +0200

Thanks Paul for the review!

Pascal, would it be possible for you to take a look and comment if you are
happy with the new version?

Thanks!

Carlos

On Mon, Aug 30, 2021 at 3:13 PM Mr. Jaehoon Paul Jeong <
[email-masked]> wrote:

> Hi Pascal,
> Here is the revision (-21) of IPWAVE PS Draft:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-21
>
> I attach the revision letter to show how I have addressed your comments on
> the revision.
>
> Chris and I have worked for this revision together.
>
> If you have further comments, please let me know.
>
> Thanks.
>
> Best Regards,
> Paul
>
>
>
> On Fri, Jun 18, 2021 at 4:42 PM Pascal Thubert via Datatracker <
> [email-masked]> wrote:
>
>> Reviewer: Pascal Thubert
>> Review result: Not Ready
>>
>> Dear authors
>>
>> In summary:
>>
>> I read a number of very good drafts collated in one, from the use cases
>> that
>> very complete and ready to publish, to the architecture and protocol
>> solution
>> in section 4 that would require more work for completeness.
>>
>> There are multiple instances in the use cases where protocols are listed
>> coming
>> out of the blue, e.g., the references to OMNI that seem artificially
>> spread
>> regardless of the context of the section. OMNI is used throughout, both
>> as an
>> open ended toolbox, and as a carpet under which all problems can be
>> hidden.
>>
>> Reading this doc, OMNI shows as an interface to a software mobile router,
>> with
>> multiple of the device physical interfaces connected to the mobile
>> router. This
>> makes the stack very simple as the complexity moves to the router. But
>> now you
>> have to implement the router. Presented as that, the OMNI router deserves
>> its
>> name, it’s indeed very rich; it seems to cover all forms of MANET (many to
>> choose from) and NEMO (and all the MIP protocol family across address
>> families), all the possible radio interfaces on which the ND problems go
>> away
>> by magic, and whatever else you want to put in there. Is that the
>> intention?
>>
>> Instead of referring to OMNI for virtually anything, the doc should refer
>> to
>> MANET for MANET things (like BYOD), NEMO for NEMO things (like MNP),
>> draft-nordmark-intarea-ippl for split subnets, and
>> draft-thubert-6man-ipv6-over-wireless for P2MP/NBMA link and subnet
>> models. And
>> then you can say that all those components can be plugged in the OMNI
>> router,
>> and you can discuss which MANET and which MIP you want, including using
>> OMNI’s
>> built in mobility.
>>
>> Note that my objections are not against the OMNI design, it might be the
>> perfect thing and I am already aware of use cases that could be served by
>> a
>> P2MP interface like OMNI in conjunction with RFC8505 on the P2P
>> subinterfaces
>> (recycling the high level design we’ve been shipping for IPv4 / frame
>> relay for
>> the last 30 years). My objection is of the way the draft uses [OMNI] as
>> the
>> magic wand that solves all the problems when what you really do is throw
>> them
>> over the fence. I’d rather you focus on problems and use cases, for which
>> there’s excellent text, and indicate what needs to be done without making
>> assumption on how the needful things will be solved.
>>
>> In agreement with a discussion on the 6MAN list, I’d suggest to split,
>> keep all
>> that’s use case and problem description and ship it, remove references to
>> protocols envisioned in the solution, and start the work on architecture
>> of the
>> solution and the protocol applicability statements separately. An
>> alternate
>> would be to centralize the discussion on protocols to annex, and explain
>> that
>> protocol A or B could be envisioned in solution space because to over
>> this gap
>> or implement that function.
>>
>> In any fashion, the current text is not ready for publication as
>> applicability
>> statement, architecture and or/solution, so the related work should be
>> removed
>> from the main text. But I find it mostly ready for use case and problem
>> statement, more below.
>>
>> Review:
>>
>> Abstract
>>
>>    This document discusses the problem statement and use cases of
>>    IPv6-based vehicular networking for Intelligent Transportation
>>    Systems (ITS).
>>
>> >>> The document goes beyond that; there was actually a thread at 6MAN
>> where
>> Bob Hinden said “ This document says it is a problem statement, but then
>> becomes a solution document.   Might be better to cut it down to only the
>> problem statement part. “ >>> Would you consider doing this? If not, why?
>> Note:
>> you may want to respond on 6MAN as well. >>> >>>I would have thought that
>> the
>> traditional steps of problem statement and applicability statement of
>> existing
>> work could be expected from IPWAVE too. >>> Please clarify the steps that
>> you
>> intend to follow next with this work.
>>
>> <snip>
>>
>> 1.  Introduction
>>
>> >>> Very readable and informative section, many thanks!
>>
>>    Along with these WAVE standards and C-V2X standards, regardless of a
>>    wireless access technology under the IP stack of a vehicle, vehicular
>>    networks can operate IP mobility with IPv6 [RFC8200] and Mobile IPv6
>>    protocols (e.g., Mobile IPv6 (MIPv6) [RFC6275], Proxy MIPv6 (PMIPv6)
>>    [RFC5213], Distributed Mobility Management (DMM) [RFC7333], Locator/
>>    ID Separation Protocol (LISP) [RFC6830BIS], and Asymmetric Extended
>>    Route Optimization (AERO) [RFC6706BIS]).
>>
>> >>> NEMO (RFC 3963) is not cited. Any reason why the vehicle would not
>> transport a network?
>>
>> <snip>
>>
>>    This document describes use cases and a problem statement about
>>    IPv6-based vehicular networking for ITS, which is named IPv6 Wireless
>>    Access in Vehicular Environments (IPWAVE).  First, it introduces the
>>    use cases for using V2V, V2I, and V2X networking in ITS.  Next, for
>>    IPv6-based vehicular networks, it makes a gap analysis of current
>>    IPv6 protocols (e.g., IPv6 Neighbor Discovery, Mobility Management,
>>    and Security & Privacy), and then enumerates requirements for the
>>    extensions of those IPv6 protocols, which are tailored to IPv6-based
>>    vehicular networking.  Thus, this document is intended to motivate
>>    development of key protocols for IPWAVE.
>>
>> >>>
>>
>> <snip>
>>
>> 2.  Terminology
>>
>> >>>
>>
>> <snip>
>>
>>    o  IP-OBU: "Internet Protocol On-Board Unit": An IP-OBU denotes a
>>       computer situated in a vehicle (e.g., car, bicycle, autobike,
>>       motor cycle, and a similar one) and a device (e.g., smartphone and
>>       IoT device).  It has at least one IP interface that runs in IEEE
>>       802.11-OCB and has an "OBU" transceiver.  Also, it may have an IP
>>       interface that runs in Cellular V2X (C-V2X) [TS-23.285-3GPP]
>>       [TR-22.886-3GPP][TS-23.287-3GPP].  See the definition of the term
>>       "OBU" in [RFC8691].
>>
>> >>> Can that be a router connecting multiple computers?
>>
>> <snip>
>>
>> 3.  Use Cases
>>
>> >>> This is another great read and an enlightening section. Maybe mention
>> in
>> the abstract that the doc also covers use cases?
>>
>> <snip>
>>
>>    Although a Layer-2 solution can provide a support for multihop
>>    communications in vehicular networks, the scalability issue related
>>    to multihop forwarding still remains when vehicles need to
>>    disseminate or forward packets toward multihop-away destinations.  In
>>    addition, the IPv6-based approach for V2V as a network layer protocol
>>    can accommodate multiple radio technologies as MAC protocols, such as
>>    5G V2X and DSRC.  Therefore, the existing IPv6 protocol can be
>>    augmented through the addition of an Overlay Multilink Network (OMNI)
>>    Interface [OMNI] and/or protocol changes in order to support both
>>    wireless single-hop/multihop V2V communications and multiple radio
>>    technologies in vehicular networks.  In such a way, vehicles can
>>    communicate with each other by V2V communications to share either an
>>    emergency situation or road hazard in a highway having multiple kinds
>>    of radio technologies, such as 5G V2X and DSRC.
>>
>> >>> This text appears in the middle of high level use case, with a crude
>> list
>> of protocols; this is not a place for it
>>
>> >>> On a 6MAN Thread, Brian Carpenter said that the above:
>> “
>> is of concern regardless of the mention of OMNI. Does it mean "can be" or
>> "needs to be"? This paragraph seems like a very short summary of a big
>> problem
>> area. At the end of page 13 there is some related discussion, which
>> mentions
>> RPL as part of the solution (good choice, IMHO) but again seems to depend
>> on
>> OMNI. I don't think the fix of simply removing references to OMNI works,
>> because it would leave a gap. In an informational document, that is not a
>> formal problem but as far as this draft describes architecture, I don't
>> think
>> that big a gap is reasonable. "OMNI" is mentioned more than 20 times in
>> the
>> document. There are also several references to AERO, which is strongly
>> associated with OMNI. “ >>> I agree with Brian. Here the document seems
>> to be
>> mixing solution with problem and putting the cart before the horse. My
>> recommendation is to stick to what needs to be done that IPv6 does not do
>> yet
>> -the reqs and gaps-; but the doc should not step in the how things will
>> be done
>> unless the group already decided to do it. The logical next steps to a PS
>> are
>> an applicability statement of existing work, and if the gaps cannot be
>> filled,
>> there may be one or more WG chartered to fill those gaps.
>>
>> >>> I’d still be happy to see an annex with leads on where the solution
>> might
>> come from like RFC 8691 does.
>>
>> <snip>
>>
>>    The existing IPv6 protocol must be augmented through the addition of
>>    an OMNI interface and/or protocol changes in order 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.
>>    Thus, IPv6 needs to be extended for multihop V2I communications.
>>
>> >>> Note that I have no clue on how well OMNI applies in that space,
>> maybe it
>> does very well; but here it comes out of the blue with no justification.
>> If you
>> mention OMNI you need to detail what it is and which of the V2V  problems
>> you
>> expect it to solve. But then, that’s beyond the scope of a PS.
>>
>> <snip>
>>
>>    The existing IPv6 protocol must be augmented through the addition of
>>    an OMNI interface and/or protocol changes in order to support
>>    wireless multihop V2X (or V2I2X) communications in an urban road
>>    network where RSUs are deployed at intersections, so a vehicle (or a
>>    pedestrian's smartphone) can reach the wireless coverage of an RSU
>>    through the multihop data forwarding of intermediate vehicles (or
>>    pedestrians' smartphones).  Thus, IPv6 needs to be extended for
>>    multihop V2X (or V2I2X) communications.
>>
>> >>> Please be more specific on what the missing functions are and whether
>> they
>> are missing from the stack development standpoint or if there’s work
>> needed
>> from the IETF. 1)      If something is really missing in our specs, the
>> text to
>> prove from the use case above is missing 2)      how OMNI serves the use
>> case
>> could be elaborated in an applicability statement of OMNI for V2xyz, but
>> it is
>> a bit blunt to present it as panacea when the problems to be solved are
>> not
>> listed. 3)      If you look at it, OMNI seems like a software mobile
>> router
>> within a bump in the stack. Can that become too big?
>>
>> >>> my view is that the text above and the similar occasions should be
>> replaced
>> by something like :
>>
>>    The existing IPv6 protocol must be augmented to provide the following
>>    functions: 1) …
>>
>> >>> and / or something like:
>>
>>    In addition to the IPv6 node requirements [RFC 8504], the IPv6 protocol
>>    stack for use in a vehicle must support 1) RFC blah, 2) …
>>
>> <snip>
>>
>>    To support applications of these V2X use cases, the functions of IPv6
>>    such as VND, VMM, and VSP are prerequisites for 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.
>>
>> >>> “the functions of IPv6 such as VND, VMM, and VSP” does not parse.
>> There’s
>> no IPv6 reference that provides those functions. If the intention is to
>> say
>> that there’s stuff to add to IPv6 to support, like, say,  VND, then this
>> document fails to define how an IPv6 VND should behave, though it’s
>> precisely
>> what I’d expect from a problem statement.
>>
>> <snip>
>>
>> 4.  Vehicular Networks
>>
>> >>> What is the purpose of section 4 as a whole, problem statement or
>> applicability statement of the listed protocols? In the former case
>> what’s the
>> problem? In the latter case it is incomplete and needs to be exported to
>> an
>> applicability statement doc with all the possible technologies evaluated.
>>
>>    This section describes an example vehicular network architecture
>>    supporting V2V, V2I, and V2X communications in vehicular networks.
>>
>> >>> I read this as presenting a context to explain what the problems are
>> instead of presenting the IPVAWE “architecture”. Maybe using the term
>> “Architecture” here is misleading and led to Bob’s comment.
>>
>> <snip>
>>
>> 4.1.  Vehicular Network Architecture
>>
>>    Figure 1 shows an example vehicular network architecture for V2I and
>>    V2V in a road network [OMNI].
>>
>> a.      Is using OMNI a decision that the WG made for the future work ?
>> what
>> does it do and what does it not do? b.      Is there work left to be
>> done? Who
>> will do that work? Or is it the expectation that OMNI has it all defined
>> already?
>>
>> <snip>
>>
>>    An existing network architecture (e.g., an IP-based aeronautical
>>    network architecture [OMNI][UAM-ITS], a network architecture of
>>    PMIPv6 [RFC5213], and a low-power and lossy network architecture
>>    [RFC6550]) can be extended to a vehicular network architecture for
>>    multihop V2V, V2I, and V2X, as shown in Figure 1.  In a highway
>>    scenario, a vehicle may not access an RSU directly because of the
>>    distance of the DSRC coverage (up to 1 km).  For example, the OMNI
>>    interface and/or RPL (IPv6 Routing Protocol for Low-Power and Lossy
>>    Networks) [RFC6550] can be extended to support a multihop V2I since a
>>    vehicle can take advantage of other vehicles as relay nodes to reach
>>    the RSU.  Also, RPL can be extended to support both multihop V2V and
>>    V2X in the similar way.
>>
>> >>> all this could fit well in annex; anyway you need to explain what you
>> expect the protocols to do and which extension is needed. In the case of
>> RPL at
>> least you indicate that it would do routing, but not why you cannot use
>> it of
>> the shelf; for OMNI, what you expect is less clear, though there’s text
>> elsewhere about the many radio interfaces that could be used for the
>> purpose,
>> and the text in the UAM below that is enlightening.
>>
>> <snip>
>>
>>                                   To support not only the mobility
>>    management of the UAM end systems, but also the multihop and
>>    multilink communications of the UAM interfaces, the UAM end systems
>>    can employ an Overlay Multilink Network (OMNI) interface [OMNI] as a
>>    virtual Non-Broadcast Multiple Access (NBMA) connection to a serving
>>    ground domain infrastructure.
>>
>> >>> Again, what is the expectation for OMNI? As an overlay it requires an
>> underlay; when connecting to a MANET it needs support for that MANET. The
>> text
>> above seems to imply that is solves everything in V2xyz like magic;
>> reminds me
>> of the IPv6 multicast abstraction that was supposed to solve the broadcast
>> problem and ended up worsening it.
>>
>> <snip>
>>
>>                             This infrastructure can be configured
>>    over the underlying data links.  The OMNI interface and its link
>>    model provide a means of multilink, multihop and mobility
>>    coordination to the legacy IPv6 ND messaging [RFC4861] according to
>>    the NBMA principle.  Thus, the OMNI link model can support efficient
>>    UAM internetworking services without additional mobility messaging,
>>    and without any modification to the IPv6 ND messaging services or
>>    link model.
>>
>> >>> Again, what is the expectation for OMNI? As an overlay it requires an
>> underlay; the text above seems to imply that is solves everything in
>> V2xyz like
>> magic; that would be a stretch, that reminds me of IPv6 multicast that was
>> supposed to solve the broadcast problem and ended up worsening it.
>>
>> <snip>
>>
>>    Multiple vehicles under the coverage of an RSU share a prefix just as
>>    mobile nodes share a prefix of a Wi-Fi access point in a wireless
>>    LAN.  This is a natural characteristic in infrastructure-based
>>    wireless networks.  For example, in Figure 1, two vehicles (i.e.,
>>    Vehicle2, and Vehicle5) can use Prefix 1 to configure their IPv6
>>    global addresses for V2I communication.  Alternatively, mobile nodes
>>    can employ an OMNI interface and use their own IPv6 Unique Local
>>    Addresses (ULAs) [RFC4193] over the wireless network without
>>    requiring the messaging of IPv6 Stateless Address Autoconfiguration
>>   (SLAAC) [RFC4862], which uses an on-link prefix provided by the
>>    (visited) wireless LAN; this technique is known as "Bring-Your-Own-
>>    Addresses".
>>
>> >>>  Is OMNI the only way to "Bring-Your-Own-Addresses”? Else the text
>> could be
>> more generic, at least use e.g., like the ref to AERO later. >>> What are
>> the
>> implications / limitations of doing that – like they can do line of sight
>> V2V
>> but not reach the internet, or the need of  a local MANET / RPL that will
>> accept to route those addresses, or the security / address ownership
>> validation
>> issues ?
>>
>> <snip>
>>
>>    A single subnet prefix announced by an RSU can span multiple vehicles
>>    in VANET.  For example, in Figure 1, for Prefix 1, three vehicles
>>    (i.e., Vehicle1, Vehicle2, and Vehicle5) can construct a connected
>>    VANET.  Also, for Prefix 2, two vehicles (i.e., Vehicle3 and
>>    Vehicle6) can construct another connected VANET, and for Prefix 3,
>>    two vehicles (i.e., Vehicle4 and Vehicle7) can construct another
>>    connected VANET.  Alternatively, each vehicle could employ an OMNI
>>    interface with their own ULAs such that no topologically-oriented
>>    subnet prefixes need be announced by the RSU.
>>
>> >>>  same as above. This seems to restate the same thing, derive an
>> address
>> from a topologically correct prefix or use your own with limitations to be
>> described.
>>
>> <snip>
>>
>>    For IPv6 packets transported over IEEE 802.11-OCB, [RFC8691]
>>    specifies several details, including Maximum Transmission Unit (MTU),
>>    frame format, link-local address, address mapping for unicast and
>>    multicast, stateless autoconfiguration, and subnet structure.  An
>>    Ethernet Adaptation (EA) layer is in charge of transforming some
>>    parameters between the IEEE 802.11 MAC layer and the IPv6 network
>>    layer, which is located between the IEEE 802.11-OCB's logical link
>>    control layer and the IPv6 network layer.  This IPv6 over 802.11-OCB
>>    can be used for both V2V and V2I in IPv6-based vehicular networks.
>>
>> >>>  solution space.
>>
>> <snip>
>>
>>    An IPv6 mobility solution is needed for the guarantee of
>>    communication continuity in vehicular networks so that a vehicle's
>>    TCP session can be continued, or UDP packets can be delivered to a
>>    vehicle as a destination without loss while it moves from an IP-RSU's
>>    wireless coverage to another IP-RSU's wireless coverage.  In
>>    Figure 1, assuming that Vehicle2 has a TCP session (or a UDP session)
>>    with a corresponding node in the vehicular cloud, Vehicle2 can move
>>    from IP-RSU1's wireless coverage to IP-RSU2's wireless coverage.  In
>>    this case, a handover for Vehicle2 needs to be performed by either a
>>    host-based mobility management scheme (e.g., MIPv6 [RFC6275]) or a
>>    network-based mobility management scheme (e.g., PMIPv6 [RFC5213] and
>>    AERO [RFC6706BIS]).
>>
>>    In the host-based mobility scheme (e.g., MIPv6), an IP-RSU plays a
>>    role of a home agent.  On the other hand, in the network-based
>>    mobility scheme (e.g., PMIPv6, an MA plays a role of a mobility
>>    management controller such as a Local Mobility Anchor (LMA) in
>>    PMIPv6, which also serves vehicles as a home agent, and an IP-RSU
>>    plays a role of an access router such as a Mobile Access Gateway
>>    (MAG) in PMIPv6 [RFC5213].  The host-based mobility scheme needs
>>    client functionality in IPv6 stack of a vehicle as a mobile node for
>>    mobility signaling message exchange between the vehicle and home
>>    agent.  On the other hand, the network-based mobility scheme does not
>>    need such a client functionality for a vehicle because the network
>>    infrastructure node (e.g., MAG in PMIPv6) as a proxy mobility agent
>>    handles the mobility signaling message exchange with the home agent
>>    (e.g., LMA in PMIPv6) for the sake of the vehicle.
>>
>>    There are a scalability issue and a route optimization issue in the
>>    network-based mobility scheme (e.g., PMIPv6) when an MA covers a
>>    large vehicular network governing many IP-RSUs.  In this case, a
>>    distributed mobility scheme (e.g., DMM [RFC7429]) can mitigate the
>>    scalability issue by distributing multiple MAs in the vehicular
>>    network such that they are positioned closer to vehicles for route
>>    optimization and bottleneck mitigation in a central MA in the
>>    network-based mobility scheme.  All these mobility approaches (i.e.,
>>    a host-based mobility scheme, network-based mobility scheme, and
>>    distributed mobility scheme) and a hybrid approach of a combination
>>    of them need to provide an efficient mobility service to vehicles
>>    moving fast and moving along with the relatively predictable
>>    trajectories along the roadways.
>>
>>    In vehicular networks, the control plane can be separated from the
>>    data plane for efficient mobility management and data forwarding by
>>    using the concept of Software-Defined Networking (SDN)
>>    [RFC7149][DMM-FPC].  Note that Forwarding Policy Configuration (FPC)
>>    in [DMM-FPC], which is a flexible mobility management system, can
>>    manage the separation of data-plane and control-plane in DMM.  In
>>    SDN, the control plane and data plane are separated for the efficient
>>    management of forwarding elements (e.g., switches and routers) where
>>    an SDN controller configures the forwarding elements in a centralized
>>    way and they perform packet forwarding according to their forwarding
>>    tables that are configured by the SDN controller.  An MA as an SDN
>>    controller needs to efficiently configure and monitor its IP-RSUs and
>>    vehicles for mobility management, location management, and security
>>    services.
>>
>>    The mobility information of a GPS receiver mounted in its vehicle
>>    (e.g., position, speed, and direction) can be used to accommodate
>>    mobility-aware proactive handover schemes, which can perform the
>>    handover of a vehicle according to its mobility and the wireless
>>    signal strength of a vehicle and an IP-RSU in a proactive way.
>>
>>    Vehicles can use the TCC as their Home Network having a home agent
>>    for mobility management as in MIPv6 [RFC6275] and PMIPv6 [RFC5213],
>>    so the TCC (or an MA inside the TCC) maintains the mobility
>>    information of vehicles for location management.  IP tunneling over
>>    the wireless link should be avoided for performance efficiency.
>>    Also, in vehicular networks, asymmetric links sometimes exist and
>>    must be considered for wireless communications such as V2V and V2I.
>>
>> >>>  This is all very informative text but does not state a problem. Is
>> there a
>> problem is left to be solved or are we assessing the applicability of
>> protocols? Could it for instance, forward point to issues discussed in
>> section
>> 5?
>>
>> <snip>
>>
>>    As shown in Figure 3, as internal networks, a vehicle's moving
>>    network and an EN's fixed network are self-contained networks having
>>    multiple subnets and having an edge router (e.g., IP-OBU and IP-RSU)
>>    for the communication with another vehicle or another EN.  The
>>    internetworking between two internal networks via V2I communication
>>    requires the exchange of the network parameters and the network
>>    prefixes of the internal networks.  For the efficiency, the network
>>    prefixes of the internal networks (as a moving network) in a vehicle
>>    need to be delegated and configured automatically.  Note that a
>>    moving network's network prefix can be called a Mobile Network Prefix
>>    (MNP) [OMNI].
>>
>> >>> Then again you’re overselling OMNI. MNP is originally defined here
>> https://datatracker.ietf.org/doc/html/rfc3963#section-2 and that’s a
>> reference
>> you can use normatively.
>>
>> <snip>
>>
>>    As shown in Figure 3, the addresses used for IPv6 transmissions over
>>    the wireless link interfaces for IP-OBU and IP-RSU can be either
>>    global IPv6 addresses, or IPv6 ULAs as long as IPv6 packets can be
>>    routed within vehicular networks [OMNI].
>>
>> >>> Then again you’re overselling OMNI. There needs to  be a routing
>> protocol
>> like a MANET that will accept to carry the
>>  MNPs, and that must be implemented by the infra and both cars. The OMNI
>> spec
>>  is clear on that. This is why at first glance I see OMNI as a full mobile
>>  router in a bump in the stack. Now what is the problem behind this? No
>> such
>>  protocol at IETF? Too many to choose from? No deployment?
>> <snip>
>>
>> When global IPv6 addresses
>>    are used, wireless interface configuration and control overhead for
>>    Duplicate Address Detection (DAD) [RFC4862] and Multicast Listener
>>    Discovery (MLD) [RFC2710][RFC3810] should be minimized to support V2I
>>    and V2X communications for vehicles moving fast along roadways; when
>>    ULAs and the OMNI interface are used, no DAD nor MLD messaging is
>>    needed.
>>
>> >>> Then again you’re overselling OMNI. Isn’t it the no dad needed a
>> property
>> of injecting a BYOA in the fabric for an GUA MIP Home Address which is
>> known to
>> be unique at home? >>> OTOH, autoconf’ing a random ULA “FD…”prefix has
>> lesser
>> DAD properties than autoconf’ing a random 64bit IID in a classical
>> subnet. So
>> who says DAD isn’t required for OMNI ULA? >>> note that IMHO DAD on
>> wireless is
>> a lot more harm than good, and I agree that with a good pseudo random
>> generator
>> the ULA has no chance to collision in the real world, as OMNI claims.
>> It’s just
>> that your argument here plays the other way, because there are less
>> random bits
>> (56)  in the ULA prefix than in the IID (62), and if one starts using more
>> prefix bits to be non-random, there will be a time when DAD on prefix is
>> needed.
>>
>> <snip>
>>
>>    Let us consider the upload/download time of a vehicle when it passes
>>    through the wireless communication coverage of an IP-RSU.  For a
>>    given typical setting where 1km is the maximum DSRC communication
>>    range [DSRC] and 100km/h is the speed limit in highway, the dwelling
>>    time can be calculated to be 72 seconds by dividing the diameter of
>>    the 2km (i.e., two times of DSRC communication range where an IP-RSU
>>    is located in the center of the circle of wireless communication) by
>>    the speed limit of 100km/h (i.e., about 28m/s).  For the 72 seconds,
>>    a vehicle passing through the coverage of an IP-RSU can upload and
>>    download data packets to/from the IP-RSU.
>>
>> <snip>
>>
>> 4.3.  V2V-based Internetworking
>>
>> >>> In this section it looks like the cars are in a stable line of sight
>> relationship. Which is probably fine for a platoon, but when you drive
>> along
>> with friends in different cars, you realize that the line of sight
>> assumption
>> does not stand over time. Soon enough, other cars meddle in, and possibly
>> one
>> of the cars drives faster and too far ahead so you need the infra to
>> relay,
>> possibly over multiple infra hops.
>>
>> >>> so in this section, I’d expect to see a Vehicle communicating with
>> another
>> one and using either line of sight or V2V relaying but also using relay
>> via V2I
>> (multihop I2I not just hub and spoke V2I2V ), alternatively to together
>> for
>> redundancy. Is that part of the problem?
>>
>> >>> reading deeper section 5 I found excellent text on routing via V and
>> via I.
>> This tells that section 4 does not play a good role at justifying section
>> 5.
>> Maybe keep section 4 for another doc?
>>
>> >>> What kind or reliability is required in a V2V use case? Do you think
>> ND can
>> handle it? Or MANET? What would be the assumption on L2 (roaming time,
>> unicast
>> vs P2MP) and on L3 (reliability ala DetNet/RAW). Should we have some L3
>> redundancy?
>>
>> <snip>
>>
>> 5.  Problem Statement
>>
>> <snip>
>>
>>    In order to specify protocols using the architecture mentioned in
>>    Section 4.1, IPv6 core protocols have to be adapted to overcome
>>    certain challenging aspects of vehicular networking.  Since the
>>    vehicles are likely to be moving at great speed, protocol exchanges
>>    need to be completed in a time relatively short compared to the
>>    lifetime of a link between a vehicle and an IP-RSU, or between two
>>    vehicles.
>>
>> >>> Any order of magnitude?
>> >>> Can you indicate whether this already rules out certain procedures,
>> e.g.
>> DAD ?
>>
>>    The lifetime of a session varies depending on the session's type such
>>    as a web surfing, voice call over IP, and DNS query.  Regardless of a
>>    session's type, to guide all the IPv6 packets to their destination
>>    host, IP mobility should be supported for the session.
>>
>> >>> this seems to be for unicast when you know who to talk to. Is there a
>> need
>> some multicast groups like anybody around interested in topic blah like I
>> could
>> be multicasting the speed of vehicles coming the other way that I crossed
>> recently, for use of vehicles that I’m crossing now, so they can see a
>> slowdown
>> on advance
>>
>>    Thus, the time constraint of a wireless link has a major impact on
>>    IPv6 Neighbor Discovery (ND).  Mobility Management (MM) is also
>>    vulnerable to disconnections that occur before the completion of
>>    identity verification and tunnel management.  This is especially true
>>    given the unreliable nature of wireless communication.  This section
>>    presents key topics such as neighbor discovery and mobility
>>    management.
>>
>> >>> Only ND? What about the MANET?
>> >>> how fast should ND be to be suitable?
>> >>> is there also a bandwidth check? You can make things much faster if
>> you
>> dedicate a lot of spectrum to it. But that can also be a waste.
>>
>> 5.1.  Neighbor Discovery
>>
>> <snip>
>>
>>    The requirements for IPv6 ND for vehicular networks are efficient DAD
>>    and NUD operations.
>>
>> >>> Not lookup? Is it the intention to use IP unicast over MAC broadcast,
>> which
>> is a good idea in my book?
>>
>>  <snip>
>>
>>       This merging and partitioning should be considered for the
>>    IPv6 ND such as IPv6 Stateless Address Autoconfiguration (SLAAC)
>>    [RFC4862].
>>
>> >>> Not lookup? Is it the intention to use IP unicast over MAC broadcast,
>> which
>> is a good idea in my book?
>>
>>  <snip>
>>
>>    Also, the partitioning of a VANET may make vehicles with the same
>>    prefix be physically unreachable.  Also, SLAAC needs to prevent IPv6
>>    address duplication due to the merging of VANETs.  According to the
>>    merging and partitioning, a destination vehicle (as an IPv6 host)
>>    needs to be distinguished as either an on-link host or an off-link
>>    host even though the source vehicle uses the same prefix as the
>>    destination vehicle.
>>
>> >>> should reference to draft-nordmark-intarea-ippl
>>
>>    To efficiently prevent IPv6 address duplication due to the VANET
>>    partitioning and merging from happening in vehicular networks, the
>>    vehicular networks need to support a vehicular-network-wide DAD by
>>    defining a scope that is compatible with the legacy DAD.  In this
>>    case, two vehicles can communicate with each other when there exists
>>    a communication path over VANET or a combination of VANETs and IP-
>>    RSUs, as shown in Figure 1.  By using the vehicular-network-wide DAD,
>>    vehicles can assure that their IPv6 addresses are unique in the
>>    vehicular network whenever they are connected to the vehicular
>>    infrastructure or become disconnected from it in the form of VANET.
>>
>> >>> Excellent
>>
>>    ND time-related parameters such as router lifetime and Neighbor
>>    Advertisement (NA) interval need to be adjusted for vehicle speed and
>>    vehicle density.  For example, the NA interval needs to be
>>    dynamically adjusted according to a vehicle's speed so that the
>>    vehicle can maintain its neighboring vehicles in a stable way,
>>    considering the collision probability with the NA messages sent by
>>    other vehicles.
>>
>> >>> Is that a problem or just an operational setting that needs to be
>> found?
>> >>> Do we need to reconsider the concepts of those timers?
>>
>> <snip>
>>
>>    Thus, in IPv6-based vehicular networking, IPv6 ND should have minimum
>>    changes for the interoperability with the legacy IPv6 ND used in the
>>    Internet, including the DAD and NUD operations.
>>
>> >>> I do not find the logical link with the text before, why is this a
>> “thus”?
>> >>> why should the ND inside the VANET be constrained to be
>> interoperable? This
>> may place constraints on the solution.
>>
>> 5.1.1.  Link Model
>>
>>    A prefix model for a vehicular network needs to facilitate the
>>
>> >>> Do you mean a “subnet model” as opposed to “prefix model”.
>> >>> it would make this piece and the next should refer to
>> draft-thubert-6man-ipv6-over-wireless for IPv6 over P2MP /NBMA, for both
>> link
>> and subnet issues. The general ideas are the same, but the gory details
>> here
>> are slightly incorrect, like this notion of prefix model than comes out
>> of the
>> blue. The model is really the subnet model for the subnet associated to
>> P2MP.
>>
>>    communication between two vehicles with the same prefix regardless of
>>    the vehicular network topology as long as there exist bidirectional
>>    E2E paths between them in the vehicular network including VANETs and
>>    IP-RSUs.  This prefix model allows vehicles with the same prefix to
>>    communicate with each other via a combination of multihop V2V and
>>    multihop V2I with VANETs and IP-RSUs.  Note that the OMNI interface
>>    supports an NBMA link model where multihop V2V and V2I communications
>>    use each mobile node's ULAs without need for any DAD or MLD
>>    messaging.
>>
>> >>> again overselling OMNI.
>> >>> I kinda agree about the OMNI interface model, nothing against that.
>> But you
>> must see that there needs a lot more than what the OMNI interface to get
>> packets across V and I hops to the destination. Like routing ala MANET,
>> redundancy handling ala DetNet because it will be very lossy, path
>> management
>> ala RAW to optimize delivery vs. spectrum… And OMNI ignores ND so it does
>> not
>> solve the ND problems above.
>>
>>    IPv6 protocols work under certain assumptions that do not necessarily
>>    hold for vehicular wireless access link types other than OMNI/NBMA
>>    [VIP-WAVE][RFC5889]; the rest of this section discusses implications
>>    for those link types that do not apply when the OMNI/NBMA link model
>>
>> >>> again overselling OMNI.
>> >>> The keyword here is P2MP / NBMA, and OMNI is one interface that
>> accepts
>> that. There are others. IBM’s IPv4 over Frame relay was already P2MP /
>> NBMA,
>> using routing to complete the partial mesh in P2MP. The text seems to
>> imply
>> that OMNI is the only way to do that and that’s wrong. Also OMNI is
>> loaded with
>> other stuff than a plain P2MP capable interface. And ND over P2MP is not
>> done
>> by OMNI, OMNI only makes classical ND worse and only works in a full
>> mesh. OTOH
>> RFC 8505, which is designed to do ND for P2MP /NBMA would indeed work
>> very well
>> within an OMNI interface and solve those problems. >>> My point is that
>> you
>> need to tell the full story or refrain from entering solution space in
>> this doc
>>
>> <snip>
>>
>>    There is a relationship between a link and a prefix, besides the
>>    different scopes that are expected from the link-local and global
>>    types of IPv6 addresses.  In an IPv6 link, it is assumed that all
>>    interfaces which are configured with the same subnet prefix and with
>>    on-link bit set can communicate with each other on an IPv6 link.
>>
>> >>> not assumed; that’s what the onlink but set tells. The conclusion
>> should be
>> that the VANET cannot set the O bit.
>>
>>    However, the vehicular link model needs to define the relationship
>>    between a link and a prefix, considering the dynamics of wireless
>>    links and the characteristics of VANET.
>>
>> <snip>
>>
>>    From the previous observation, a vehicular link model should consider
>>    the frequent partitioning and merging of VANETs due to vehicle
>>    mobility.  Therefore, the vehicular link model needs to use an on-
>>    link prefix and off-link prefix according to the network topology of
>>    vehicles such as a one-hop reachable network and a multihop reachable
>>
>> >>> No, the once a node saw a O bit set that sticks even if it sees other
>> advertisements of the PIO with the O bit not set. >>> This is a global and
>> intrinsic property of the prefix (and an attack vector that could be
>> mentioned
>> in the sec section). >>> the VANET prefix must never come with the O bit
>> set.
>>
>> <snip>
>>
>>    network (or partitioned networks).  If the vehicles with the same
>>    prefix are reachable from each other in one hop, the prefix should be
>>    on-link.
>>
>> >>>> No, see above; but the router may redirect though it is really risky
>> unless this is a stable situation like a parking place.
>>
>>    Thus, in IPv6-based vehicular networking, the vehicular link model
>>    should have minimum changes for interoperability with standard IPv6
>>    links in an efficient fashion to support IPv6 DAD, MLD and NUD
>>    operations.  When the OMNI NBMA link model is used, there are no link
>>    model changes nor DAD/MLD messaging required.
>>
>> >>>> again overselling OMNI.
>> >>>> You need a good P2MP subnet model with routing support when the mesh
>> is
>> partial. My company alone has been shipping million of nodes that build
>> subnets
>> of thousands, and that was done using IETF standards.
>>
>> <snip>
>>
>>    For vehicular networks with high mobility and density, the DAD needs
>>    to be performed efficiently with minimum overhead so that the
>>    vehicles can exchange a driving safety message (e.g., collision
>>    avoidance and accident notification) with each other with a short
>>    interval (e.g., 0.5 second) by a technical report from NHTSA
>>    (National Highway Traffic Safety Administration) [NHTSA-ACAS-Report].
>>    Such a driving safety message may include a vehicle's mobility
>>    information (i.e., position, speed, direction, and acceleration/
>>    deceleration).  The exchange interval of this message is 0.5 second,
>>    which is required to allow a driver to avoid a rear-end crash from
>>    another vehicle.
>>
>> >>> IPv6 over broadcast MAC (used to be called internet 0, 10+ years ago)
>> solves that MAC issue since there is no MAC.
>>
>> 5.1.3.  Routing
>>
>>    For multihop V2V communications in either a VANET or VANETs via IP-
>>    RSUs, a vehicular Mobile Ad Hoc Networks (MANET) routing protocol may
>>    be required to support both unicast and multicast in the links of the
>>    subnet with the same IPv6 prefix.  However, it will be costly to run
>>    both vehicular ND and a vehicular ad hoc routing protocol in terms of
>>    control traffic overhead [ID-Multicast-Problems].
>>
>> >>> we do that with IETF standards on battery operated devices already.
>> Using
>> RFC 8505 for the UNI and RPL for the NNI. It is scalable (we’ve seen 30
>> hops in
>> meshes of thousands in the real world though it’s not the normal
>> operational
>> model, but can happen to maintain connectivity during the reboot of a
>> root) and
>> does not use broadcast. RPL was initially designed as a V2V2V protocol but
>> found its market on the IoT. I’m sure the protocol would gladly come back
>> to
>> its roots.
>>
>>    A routing protocol for a VANET may cause redundant wireless frames in
>>    the air to check the neighborhood of each vehicle and compute the
>>    routing information in a VANET with a dynamic network topology
>>    because the IPv6 ND is used to check the neighborhood of each
>>    vehicle.  Thus, the vehicular routing needs to take advantage of the
>>    IPv6 ND to minimize its control overhead.
>>
>> >>> A clean description of the interaction of RPL and RFC 8505 in our IoT
>> networks. Note that the speed of the PHY in VANET balanced the
>> instability of
>> the topology, and RPL still applies. Note also that RPL uses DV with a
>> routing
>> stretch in order to minimize the topology awareness that’s needed in each
>> node,
>> which results in minimal signaling.
>>
>> 5.2.  Mobility Management
>>
>> <snip>
>>
>>    For a mobility management scheme in a shared link, where the wireless
>>    subnets of multiple IP-RSUs share the same prefix, an efficient
>>    vehicular-network-wide DAD is required.  If DHCPv6 is used to assign
>>    a unique IPv6 address to each vehicle in this shared link,
>>
>> >>> I would not use the term link, or shared. Maybe shared link -> domain?
>> <snip>
>>
>> the DAD is
>>    not required.  On the other hand, for a mobility management scheme
>>    with a unique prefix per mobile node (e.g., PMIPv6 [RFC5213] and OMNI
>>    [OMNI]), DAD is not required because the IPv6 address of a vehicle's
>>    external wireless interface is guaranteed to be unique.
>>
>> >>> again overselling OMNI
>> >>> As I said earlier, this is wring there are (64*) more chances of a
>> collision in OMNI prefixes than in IPv6 IIDs. >>> OMNI prefixes can
>> collision,
>> home addresses that are unique on a home network cannot. >>> Now if both
>> the
>> OMNI prefix and the IID are good randoms, then obviously, the chances of
>> collisions round up to 0. >>> Collision is certainly not my worst fear.
>>
>>   There is a
>>    tradeoff between the prefix usage efficiency and DAD overhead.  Thus,
>>    the IPv6 address autoconfiguration for vehicular networks needs to
>>    consider this tradeoff to support efficient mobility management.
>>
>> >>> This is way too superficial and hides the reality of things.
>> - Using a VANET Infra prefix allows direct routability to the internet
>> which
>> BYOA does not since the BYOA is not topologically correct. Yes, it costs
>> a DAD
>> with classic ND, but it does not with RCF8505 and the draft fails to
>> mention
>> that. - A BYOA needs a tunnel home, and the node needs to know who is
>> reachable
>> inside the VANET and what is not to decide to tunnel or not; this is a
>> difficult problem (vs. control place overhead) that is not discussed here.
>>
>> <snip>
>>
>>    For the case of a multihomed network, a vehicle can follow the first-
>>    hop router selection rule described in [RFC8028].  That is, the
>>    vehicle should select its default router for each prefix by
>>    preferring the router that advertised the prefix.
>>
>> >>> Still router discovery (in and out) must be very fast. Thing of the RA
>> intervale in MIPv6. Is that sufficient? Too expensive?
>>
>> <snip>
>>
>> 6.  Security Considerations
>> >>> Any discussion on the security of classical ND and other operational
>> issues
>> (rfc6583) ?
>>
>> <snip>
>>
>>    Security and privacy are paramount in V2I, V2V, and V2X networking.
>>    Vehicles and infrastructure must be authenticated in order to
>>    participate in vehicular networking.  Also, in-vehicle devices (e.g.,
>>    ECU) and a driver/passenger's mobile devices (e.g., smartphone and
>>    tablet PC) in a vehicle need to communicate with other in-vehicle
>>    devices and another driver/passenger's mobile devices in another
>>    vehicle, or other servers behind an IP-RSU in a secure way.  Even
>>    though a vehicle is perfectly authenticated and legitimate, it may be
>>    hacked for running malicious applications to track and collect its
>>    and other vehicles' information.  In this case, an attack mitigation
>>    process may be required to reduce the aftermath of malicious
>>    behaviors.
>>
>> >>> The section should mention that both with classical ND and BYOA,
>> addresses
>> can be impersonated, and RFC 8928 protects against that in both cases
>> while
>> maintaining privacy.
>>
>>    Even though vehicles can be authenticated with valid certificates by
>>    an authentication server in the vehicular cloud, the authenticated
>>
>> >>> Is PKI feasible (deploying it in every car?). Is it fast enough? Is it
>> really what IPWAVE thinks vehicle should use????? >>> e.g. why would one
>> need
>> to authenticate to a V2I network? >>> from the text earlier in the doc, it
>> seemed that what you really want is access that is fast to join, capable
>> of
>> offering the reachability you want, anonymous, and innocuous (cars can
>> not harm
>> one another).
>>
>>    vehicles may harm other vehicles, so their communication activities
>>    need to be logged in either a central way through a logging server
>>    (e.g., TCC) in the vehicular cloud or a distributed way (e.g.,
>>    blockchain [Bitcoin]) along with other vehicles or infrastructure.
>>    For the non-repudiation of the harmful activities of malicious nodes,
>>    a blockchain technology can be used [Bitcoin].  Each message from a
>>    vehicle can be treated as a transaction and the neighboring vehicles
>>    can play the role of peers in a consensus method of a blockchain
>>    [Bitcoin][Vehicular-BlockChain].  For a blockchain's efficient
>>    consensus in vehicular networks having fast moving vehicles, a new
>>    consensus algorithm needs to be developed or an existing consensus
>>    algorithm needs to be enhanced.
>>
>> >>> solution space; better express the  security needs since this is a PS.
>>
>> <snip>
>>
>>    To identify malicious vehicles among vehicles, an authentication
>>    method is required.
>>
>> >>> No. As said earlier a vehicle can be infected. You need
>> innocuousness.which
>> can come from things like isolation, zerotrust, and protocols that are
>> difficult to hack around. Classical IPv6 ND is open bar. RFC 8505/8928 is
>> protected by construction, anonymous, and fast.
>>
>> <snip>
>>
>>    For the setup of a secure channel over IPsec or TLS, the multihop V2I
>>    communications over DSRC is required in a highway for the
>>    authentication by involving multiple intermediate vehicles as relay
>>    nodes toward an IP-RSU connected to an authentication server in the
>>    vehicular cloud.  The V2I communications over 5G V2X (or LTE V2X) is
>>    required to allow a vehicle to communicate directly with a gNodeB (or
>>    eNodeB) connected to an authentication server in the vehicular cloud.
>>
>> >>> solution space. Instead, you could mention that setting up secured
>> channels
>> between cars that cross one another might not complete in time to
>> establish the
>> communication channel, and that the innocuousness must come from
>> zerotrust in
>> the transactions between the cars.
>>    For the IPv6 ND, the DAD is required to ensure the uniqueness of the
>>    IPv6 address of a vehicle's wireless interface.
>>
>> >>> for classical ND (SLAAC) that’s true. That is not with RFC 8505,
>> since the
>> infra maintains a table of all addresses in use in the prefix and blocks
>> duplicates without the RFC 4862 DAD method. The stateful autoconf address
>> grant
>> is immediate.
>>
>>                                This DAD can be used
>>    as a flooding attack that uses the DAD-related ND packets
>>    disseminated over the VANET or vehicular networks.
>>
>> >>> also for DOS attacks. You can block a owner from using an address. A
>> reference to rfc6959 is much needed here.
>>
>> <snip>
>>
>>  This possibility
>>    indicates that the vehicles and IP-RSUs need to filter out suspicious
>>    ND traffic in advance.  Based on the SEND [RFC3971] mechanism, the
>>    authentication for routers (i.e., IP-RSUs) can be conducted by only
>>    selecting an IP-RSU that has a certification path toward trusted
>>    parties.  For authenticating other vehicles, the cryptographically
>>    generated address (CGA) can be used to verify the true owner of a
>>    received ND message, which requires to use the CGA ND option in the
>>    ND protocols.  For a general protection of the ND mechanism, the RSA
>>    Signature ND option can also be used to protect the integrity of the
>>    messages by public key signatures.  For a more advanced
>>    authentication mechanism, a distributed blockchain-based mechanism
>>    [Vehicular-BlockChain] can be used.
>>
>> >>> solution space. Again, the draft should focus on problems and needs.
>> The
>> problem here is that SEND is complex, and not implemented in the major
>> stack.
>> It relies on PKI for trusting the router. The V2I need is a zerotrust
>> model
>> where one V, the other local Vs, and the I, can help each other
>> anonymously and
>> harmlessly. <snip>
>>
>> 8.  Informative References
>>
>> >>> no normative reference?
>>
>> >>> no normative reference?
>>
>> <snip>
>>
>> Voila!
>>
>> Keep safe;
>>
>> Pascal
>>
>>
>>
>> _______________________________________________
>> its mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/its
>>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 1 Sep 2021 20:09:14 +0000

Hello Carlos

Will do ASAP 😀

Regards,

Pascal

Le 1 sept. 2021 à 20:49, CARLOS JESUS BERNARDOS CANO <[email-masked]> a écrit :

Pascal, would it be possible for you to take a look and comment if you are happy with the new version?

Thanks!

Carlos

On Mon, Aug 30, 2021 at 3:13 PM Mr. Jaehoon Paul Jeong <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pascal,
Here is the revision (-21) of IPWAVE PS Draft:
https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-21

I attach the revision letter to show how I have addressed your comments on the revision.

Thanks.

Best Regards,
Paul

On Fri, Jun 18, 2021 at 4:42 PM Pascal Thubert via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Reviewer: Pascal Thubert
Review result: Not Ready

Dear authors

In summary:

I read a number of very good drafts collated in one, from the use cases that
very complete and ready to publish, to the architecture and protocol solution
in section 4 that would require more work for completeness.

There are multiple instances in the use cases where protocols are listed coming
out of the blue, e.g., the references to OMNI that seem artificially spread
regardless of the context of the section. OMNI is used throughout, both as an
open ended toolbox, and as a carpet under which all problems can be hidden.

Reading this doc, OMNI shows as an interface to a software mobile router, with
multiple of the device physical interfaces connected to the mobile router. This
makes the stack very simple as the complexity moves to the router. But now you
have to implement the router. Presented as that, the OMNI router deserves its
name, it’s indeed very rich; it seems to cover all forms of MANET (many to
choose from) and NEMO (and all the MIP protocol family across address
families), all the possible radio interfaces on which the ND problems go away
by magic, and whatever else you want to put in there. Is that the intention?

Instead of referring to OMNI for virtually anything, the doc should refer to
MANET for MANET things (like BYOD), NEMO for NEMO things (like MNP),
draft-nordmark-intarea-ippl for split subnets, and
draft-thubert-6man-ipv6-over-wireless for P2MP/NBMA link and subnet models. And
then you can say that all those components can be plugged in the OMNI router,
and you can discuss which MANET and which MIP you want, including using OMNI’s
built in mobility.

Note that my objections are not against the OMNI design, it might be the
perfect thing and I am already aware of use cases that could be served by a
P2MP interface like OMNI in conjunction with RFC8505 on the P2P subinterfaces
(recycling the high level design we’ve been shipping for IPv4 / frame relay for
the last 30 years). My objection is of the way the draft uses [OMNI] as the
magic wand that solves all the problems when what you really do is throw them
over the fence. I’d rather you focus on problems and use cases, for which
there’s excellent text, and indicate what needs to be done without making
assumption on how the needful things will be solved.

In agreement with a discussion on the 6MAN list, I’d suggest to split, keep all
that’s use case and problem description and ship it, remove references to
protocols envisioned in the solution, and start the work on architecture of the
solution and the protocol applicability statements separately. An alternate
would be to centralize the discussion on protocols to annex, and explain that
protocol A or B could be envisioned in solution space because to over this gap
or implement that function.

In any fashion, the current text is not ready for publication as applicability
statement, architecture and or/solution, so the related work should be removed
from the main text. But I find it mostly ready for use case and problem
statement, more below.

Review:

Abstract

>>> The document goes beyond that; there was actually a thread at 6MAN where
Bob Hinden said “ This document says it is a problem statement, but then
becomes a solution document.   Might be better to cut it down to only the
problem statement part. “ >>> Would you consider doing this? If not, why? Note:
you may want to respond on 6MAN as well. >>> >>>I would have thought that the
traditional steps of problem statement and applicability statement of existing
work could be expected from IPWAVE too. >>> Please clarify the steps that you
intend to follow next with this work.

<snip>

1.  Introduction

transport a network?

<snip>

<snip>

2.  Terminology

<snip>

<snip>

3.  Use Cases

>>> This is another great read and an enlightening section. Maybe mention in

<snip>

>>> This text appears in the middle of high level use case, with a crude list

“
is of concern regardless of the mention of OMNI. Does it mean "can be" or
"needs to be"? This paragraph seems like a very short summary of a big problem
area. At the end of page 13 there is some related discussion, which mentions
RPL as part of the solution (good choice, IMHO) but again seems to depend on
OMNI. I don't think the fix of simply removing references to OMNI works,
because it would leave a gap. In an informational document, that is not a
formal problem but as far as this draft describes architecture, I don't think
that big a gap is reasonable. "OMNI" is mentioned more than 20 times in the
document. There are also several references to AERO, which is strongly
associated with OMNI. “ >>> I agree with Brian. Here the document seems to be
mixing solution with problem and putting the cart before the horse. My
recommendation is to stick to what needs to be done that IPv6 does not do yet
-the reqs and gaps-; but the doc should not step in the how things will be done
unless the group already decided to do it. The logical next steps to a PS are
an applicability statement of existing work, and if the gaps cannot be filled,
there may be one or more WG chartered to fill those gaps.

>>> I’d still be happy to see an annex with leads on where the solution might

<snip>

>>> Note that I have no clue on how well OMNI applies in that space, maybe it
does very well; but here it comes out of the blue with no justification. If you
mention OMNI you need to detail what it is and which of the V2V  problems you
expect it to solve. But then, that’s beyond the scope of a PS.

<snip>

>>> Please be more specific on what the missing functions are and whether they
are missing from the stack development standpoint or if there’s work needed
from the IETF. 1)      If something is really missing in our specs, the text to
prove from the use case above is missing 2)      how OMNI serves the use case
could be elaborated in an applicability statement of OMNI for V2xyz, but it is
a bit blunt to present it as panacea when the problems to be solved are not
listed. 3)      If you look at it, OMNI seems like a software mobile router
within a bump in the stack. Can that become too big?

>>> my view is that the text above and the similar occasions should be replaced
by something like :

<snip>

>>> “the functions of IPv6 such as VND, VMM, and VSP” does not parse. There’s
no IPv6 reference that provides those functions. If the intention is to say
that there’s stuff to add to IPv6 to support, like, say,  VND, then this
document fails to define how an IPv6 VND should behave, though it’s precisely
what I’d expect from a problem statement.

<snip>

4.  Vehicular Networks

>>> What is the purpose of section 4 as a whole, problem statement or
applicability statement of the listed protocols? In the former case what’s the
problem? In the latter case it is incomplete and needs to be exported to an
applicability statement doc with all the possible technologies evaluated.

<snip>

a.      Is using OMNI a decision that the WG made for the future work ? what
does it do and what does it not do? b.      Is there work left to be done? Who
will do that work? Or is it the expectation that OMNI has it all defined
already?

<snip>

>>> all this could fit well in annex; anyway you need to explain what you
expect the protocols to do and which extension is needed. In the case of RPL at
least you indicate that it would do routing, but not why you cannot use it of
the shelf; for OMNI, what you expect is less clear, though there’s text
elsewhere about the many radio interfaces that could be used for the purpose,
and the text in the UAM below that is enlightening.

<snip>

>>> Again, what is the expectation for OMNI? As an overlay it requires an
underlay; when connecting to a MANET it needs support for that MANET. The text
above seems to imply that is solves everything in V2xyz like magic; reminds me
of the IPv6 multicast abstraction that was supposed to solve the broadcast
problem and ended up worsening it.

<snip>

>>> Again, what is the expectation for OMNI? As an overlay it requires an
underlay; the text above seems to imply that is solves everything in V2xyz like
magic; that would be a stretch, that reminds me of IPv6 multicast that was
supposed to solve the broadcast problem and ended up worsening it.

<snip>

>>>  Is OMNI the only way to "Bring-Your-Own-Addresses”? Else the text could be
more generic, at least use e.g., like the ref to AERO later. >>> What are the
implications / limitations of doing that – like they can do line of sight V2V
but not reach the internet, or the need of  a local MANET / RPL that will
accept to route those addresses, or the security / address ownership validation
issues ?

<snip>

>>>  same as above. This seems to restate the same thing, derive an address

<snip>

<snip>

>>>  This is all very informative text but does not state a problem. Is there a
problem is left to be solved or are we assessing the applicability of
protocols? Could it for instance, forward point to issues discussed in section
5?

<snip>

>>> Then again you’re overselling OMNI. MNP is originally defined here
https://datatracker.ietf.org/doc/html/rfc3963#section-2 and that’s a reference
you can use normatively.

<snip>

>>> Then again you’re overselling OMNI. There needs to  be a routing protocol
like a MANET that will accept to carry the
 MNPs, and that must be implemented by the infra and both cars. The OMNI spec
 is clear on that. This is why at first glance I see OMNI as a full mobile
 router in a bump in the stack. Now what is the problem behind this? No such
 protocol at IETF? Too many to choose from? No deployment?
<snip>

>>> Then again you’re overselling OMNI. Isn’t it the no dad needed a property
of injecting a BYOA in the fabric for an GUA MIP Home Address which is known to
be unique at home? >>> OTOH, autoconf’ing a random ULA “FD…”prefix has lesser
DAD properties than autoconf’ing a random 64bit IID in a classical subnet. So
who says DAD isn’t required for OMNI ULA? >>> note that IMHO DAD on wireless is
a lot more harm than good, and I agree that with a good pseudo random generator
the ULA has no chance to collision in the real world, as OMNI claims. It’s just
that your argument here plays the other way, because there are less random bits
(56)  in the ULA prefix than in the IID (62), and if one starts using more
prefix bits to be non-random, there will be a time when DAD on prefix is needed.

<snip>

<snip>

>>> In this section it looks like the cars are in a stable line of sight
relationship. Which is probably fine for a platoon, but when you drive along
with friends in different cars, you realize that the line of sight assumption
does not stand over time. Soon enough, other cars meddle in, and possibly one
of the cars drives faster and too far ahead so you need the infra to relay,
possibly over multiple infra hops.

>>> so in this section, I’d expect to see a Vehicle communicating with another
one and using either line of sight or V2V relaying but also using relay via V2I
(multihop I2I not just hub and spoke V2I2V ), alternatively to together for
redundancy. Is that part of the problem?

>>> reading deeper section 5 I found excellent text on routing via V and via I.
This tells that section 4 does not play a good role at justifying section 5.
Maybe keep section 4 for another doc?

>>> What kind or reliability is required in a V2V use case? Do you think ND can
handle it? Or MANET? What would be the assumption on L2 (roaming time, unicast
vs P2MP) and on L3 (reliability ala DetNet/RAW). Should we have some L3
redundancy?

<snip>

5.  Problem Statement

<snip>

>>> Any order of magnitude?
>>> Can you indicate whether this already rules out certain procedures, e.g.
DAD ?

>>> this seems to be for unicast when you know who to talk to. Is there a need
some multicast groups like anybody around interested in topic blah like I could
be multicasting the speed of vehicles coming the other way that I crossed
recently, for use of vehicles that I’m crossing now, so they can see a slowdown
on advance

>>> is there also a bandwidth check? You can make things much faster if you

5.1.  Neighbor Discovery

<snip>

>>> Not lookup? Is it the intention to use IP unicast over MAC broadcast, which

 <snip>

>>> Not lookup? Is it the intention to use IP unicast over MAC broadcast, which

 <snip>

>>> Is that a problem or just an operational setting that needs to be found?

<snip>

>>> I do not find the logical link with the text before, why is this a “thus”?
>>> why should the ND inside the VANET be constrained to be interoperable? This

5.1.1.  Link Model

>>> it would make this piece and the next should refer to
draft-thubert-6man-ipv6-over-wireless for IPv6 over P2MP /NBMA, for both link
and subnet issues. The general ideas are the same, but the gory details here
are slightly incorrect, like this notion of prefix model than comes out of the
blue. The model is really the subnet model for the subnet associated to P2MP.

>>> again overselling OMNI.
>>> I kinda agree about the OMNI interface model, nothing against that. But you
must see that there needs a lot more than what the OMNI interface to get
packets across V and I hops to the destination. Like routing ala MANET,
redundancy handling ala DetNet because it will be very lossy, path management
ala RAW to optimize delivery vs. spectrum… And OMNI ignores ND so it does not
solve the ND problems above.

>>> again overselling OMNI.
>>> The keyword here is P2MP / NBMA, and OMNI is one interface that accepts
that. There are others. IBM’s IPv4 over Frame relay was already P2MP / NBMA,
using routing to complete the partial mesh in P2MP. The text seems to imply
that OMNI is the only way to do that and that’s wrong. Also OMNI is loaded with
other stuff than a plain P2MP capable interface. And ND over P2MP is not done
by OMNI, OMNI only makes classical ND worse and only works in a full mesh. OTOH
RFC 8505, which is designed to do ND for P2MP /NBMA would indeed work very well
within an OMNI interface and solve those problems. >>> My point is that you
need to tell the full story or refrain from entering solution space in this doc

<snip>

>>> not assumed; that’s what the onlink but set tells. The conclusion should be

<snip>

advertisements of the PIO with the O bit not set. >>> This is a global and
intrinsic property of the prefix (and an attack vector that could be mentioned
in the sec section). >>> the VANET prefix must never come with the O bit set.

<snip>

>>>> again overselling OMNI.
>>>> You need a good P2MP subnet model with routing support when the mesh is
partial. My company alone has been shipping million of nodes that build subnets
of thousands, and that was done using IETF standards.

<snip>

5.1.3.  Routing

>>> we do that with IETF standards on battery operated devices already. Using
RFC 8505 for the UNI and RPL for the NNI. It is scalable (we’ve seen 30 hops in
meshes of thousands in the real world though it’s not the normal operational
model, but can happen to maintain connectivity during the reboot of a root) and
does not use broadcast. RPL was initially designed as a V2V2V protocol but
found its market on the IoT. I’m sure the protocol would gladly come back to
its roots.

>>> A clean description of the interaction of RPL and RFC 8505 in our IoT
networks. Note that the speed of the PHY in VANET balanced the instability of
the topology, and RPL still applies. Note also that RPL uses DV with a routing
stretch in order to minimize the topology awareness that’s needed in each node,
which results in minimal signaling.

5.2.  Mobility Management

<snip>

<snip>

the DAD is

>>> As I said earlier, this is wring there are (64*) more chances of a
collision in OMNI prefixes than in IPv6 IIDs. >>> OMNI prefixes can collision,
home addresses that are unique on a home network cannot. >>> Now if both the
OMNI prefix and the IID are good randoms, then obviously, the chances of
collisions round up to 0. >>> Collision is certainly not my worst fear.

  There is a

>>> This is way too superficial and hides the reality of things.
- Using a VANET Infra prefix allows direct routability to the internet which
BYOA does not since the BYOA is not topologically correct. Yes, it costs a DAD
with classic ND, but it does not with RCF8505 and the draft fails to mention
that. - A BYOA needs a tunnel home, and the node needs to know who is reachable
inside the VANET and what is not to decide to tunnel or not; this is a
difficult problem (vs. control place overhead) that is not discussed here.

<snip>

<snip>

>>> Any discussion on the security of classical ND and other operational issues
(rfc6583) ?

<snip>

>>> The section should mention that both with classical ND and BYOA, addresses
can be impersonated, and RFC 8928 protects against that in both cases while
maintaining privacy.

>>> Is PKI feasible (deploying it in every car?). Is it fast enough? Is it
really what IPWAVE thinks vehicle should use????? >>> e.g. why would one need
to authenticate to a V2I network? >>> from the text earlier in the doc, it
seemed that what you really want is access that is fast to join, capable of
offering the reachability you want, anonymous, and innocuous (cars can not harm
one another).

<snip>

>>> No. As said earlier a vehicle can be infected. You need innocuousness.which

<snip>

>>> solution space. Instead, you could mention that setting up secured channels
between cars that cross one another might not complete in time to establish the
communication channel, and that the innocuousness must come from zerotrust in
the transactions between the cars.
   For the IPv6 ND, the DAD is required to ensure the uniqueness of the
   IPv6 address of a vehicle's wireless interface.

>>> for classical ND (SLAAC) that’s true. That is not with RFC 8505, since the
infra maintains a table of all addresses in use in the prefix and blocks
duplicates without the RFC 4862 DAD method. The stateful autoconf address grant
is immediate.

                               This DAD can be used

<snip>

 This possibility

>>> solution space. Again, the draft should focus on problems and needs. The
problem here is that SEND is complex, and not implemented in the major stack.
It relies on PKI for trusting the router. The V2I need is a zerotrust model
where one V, the other local Vs, and the I, can help each other anonymously and
harmlessly. <snip>

<snip>

Voila!

Keep safe;

Pascal

_______________________________________________
its mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/its

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 2 Sep 2021 06:49:39 +0000

Hello Paul

This is absolutely excellent. I’m very happy will all the changes and your attached pdf made my life as a reviewer a lot simpler.

This is really a great way of progressing together. Many thanks for that!

I’m all good but for a little snippet in the new text which is actually incorrect, and denotes a usual misunderstanding of RPL that your doc may help correct for the future:

“
Although RPL can be used in IPv6-based vehicular networks, it is primarily designed for lossy
networks, which puts energy efficiency first. In addition, the topology it considers may not
quickly scale up and down for IPv6-based vehicular networks, since the mobility of vehicles is
much more diverse with a high speed, so it can frequently alter a tree-like topology formed by
RPL, which may cause network fragmentation and merging with more control traffic
“

The roots of my contribution to RPL are in vehicular networks, exactly the use case you describe. Based on that experience (including some actual test with NASA) I’d change the text above with:

“
RPL is primarily designed to minimize the control plane activity, that is the relative amount of routing protocol exchanges vs. data traffic; this approach is beneficial for situations where the power and bandwidth are scarce (e.g., an IoT LLN where RPL is typically used today), but also in situations of high relative mobility between the nodes in the network (aka swarming, e.g., within a variable set of vehicles with a similar global motion, or a toon of drones).
To reduce the routing exchanges, RPL leverages a Distance Vector approach, which does not need a global knowledge of the topology, and only optimizes the routes to and from the root, allowing P2P paths to be stretched. Although RPL installs its routes proactively, it only maintains them lazily, in reaction to actual traffic, or as a slow background activity. Additionally, RPL leverages the concept of an objective function, which allows to adapt the activity of the routing protocol to the use case, e.g., type, speed, and quality of the radios. RPL does not need converge, and provides connectivity to most nodes most of the time. The default route towards the Root is maintained aggressively and may change while a packet progresses without causing loops, so the packet will still reach the root. In non-storing mode, a node inside the mesh/swarm that changes its point(s) of attachment to the graph informs the root with a single unicast packet the flows along the default route, and the connectivity is restored immediately; this mode is preferable for use cases where internet connectivity is dominant. OTOH, in storing mode, the routing stretch is reduced, for a better P2P connectivity, while the internet connectivity is restored more slowly, time for the DV operation to operate hop-by-hop. While a RPL topology can quickly scale up and down and fits the needs of mobility of vehicles, the total performance of the system will also depend on how quickly a node can form an address, join the mesh (including AAA), and manage its global mobility to become reachable from outside the mesh.
“

Otherwise, all good!

Take care,

Pascal

From: Mr. Jaehoon Paul Jeong <[email-masked]>
Sent: lundi 30 août 2021 15:12
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]; Last Call <[email-masked]>; [email-masked]; [email-masked]; Russ Housley <[email-masked]>; CARLOS JESUS BERNARDOS CANO <[email-masked]>; skku-iotlab-members <[email-masked]>; Chris Shen <[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked]>
Subject: Re: [ipwave] Intdir last call review of draft-ietf-ipwave-vehicular-networking-20

Hi Pascal,

Thanks.

Best Regards,
Paul

Dear authors

In summary:

Review:

Abstract

<snip>

1.  Introduction

transport a network?

<snip>

<snip>

2.  Terminology

<snip>

<snip>

3.  Use Cases

<snip>

“

<snip>

<snip>

by something like :

<snip>

<snip>

4.  Vehicular Networks

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

5.  Problem Statement

<snip>

DAD ?

5.1.  Neighbor Discovery

<snip>

 <snip>

 <snip>

<snip>

5.1.1.  Link Model

<snip>

<snip>

<snip>

<snip>

5.1.3.  Routing

5.2.  Mobility Management

<snip>

<snip>

the DAD is

  There is a

<snip>

<snip>

(rfc6583) ?

<snip>

<snip>

<snip>

                               This DAD can be used

<snip>

 This possibility

<snip>

Voila!

Keep safe;

Pascal

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 2 Sep 2021 16:17:38 +0900

Hi Pascal,
I sincerely appreciate your super-fast feedback.
I will address your comments and submit the revision today.

Thanks.

Best Regards,
Paul

On Thu, Sep 2, 2021 at 3:49 PM Pascal Thubert (pthubert) <[email-masked]>
wrote:

> Hello Paul
>
>
>
> This is absolutely excellent. I’m very happy will all the changes and your
> attached pdf made my life as a reviewer a lot simpler.
>
>
>
> I’m all good but for a little snippet in the new text which is actually
> incorrect, and denotes a usual misunderstanding of RPL that your doc may
> help correct for the future:
>
>
>
> “
>
> The roots of my contribution to RPL are in vehicular networks, exactly the
> use case you describe. Based on that experience (including some actual test
> with NASA) I’d change the text above with:
>
>
>
>
>
> “
>
> RPL is primarily designed to minimize the control plane activity, that is
> the relative amount of routing protocol exchanges vs. data traffic; this
> approach is beneficial for situations where the power and bandwidth are
> scarce (e.g., an IoT LLN where RPL is typically used today), but also in
> situations of high relative mobility between the nodes in the network (aka
> swarming, e.g., within a variable set of vehicles with a similar global
> motion, or a toon of drones).
>
> To reduce the routing exchanges, RPL leverages a Distance Vector approach,
> which does not need a global knowledge of the topology, and only optimizes
> the routes to and from the root, allowing P2P paths to be stretched.
> Although RPL installs its routes proactively, it only maintains them
> lazily, in reaction to actual traffic, or as a slow background activity.
> Additionally, RPL leverages the concept of an objective function, which
> allows to adapt the activity of the routing protocol to the use case, e.g.,
> type, speed, and quality of the radios. RPL does not need converge, and
> provides connectivity to most nodes most of the time. The default route
> towards the Root is maintained aggressively and may change while a packet
> progresses without causing loops, so the packet will still reach the root.
> In non-storing mode, a node inside the mesh/swarm that changes its point(s)
> of attachment to the graph informs the root with a single unicast packet
> the flows along the default route, and the connectivity is restored
> immediately; this mode is preferable for use cases where internet
> connectivity is dominant. OTOH, in storing mode, the routing stretch is
> reduced, for a better P2P connectivity, while the internet connectivity is
> restored more slowly, time for the DV operation to operate hop-by-hop.
> While a RPL topology can quickly scale up and down and fits the needs of
> mobility of vehicles, the total performance of the system will also depend
> on how quickly a node can form an address, join the mesh (including AAA),
> and manage its global mobility to become reachable from outside the mesh.
>
> “
>
>
>
> Otherwise, all good!
>
>
>
> Take care,
>
>
>
> Pascal
>
>
>
>
>
> *From:* Mr. Jaehoon Paul Jeong <[email-masked]>
> *Sent:* lundi 30 août 2021 15:12
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* [email-masked]; Last Call <[email-masked]>;
> [email-masked]; [email-masked]; Russ
> Housley <[email-masked]>; CARLOS JESUS BERNARDOS CANO <
> [email-masked]>; skku-iotlab-members <
> [email-masked]>; Chris Shen <[email-masked]>;
> Mr. Jaehoon Paul Jeong <[email-masked]>
> *Subject:* Re: [ipwave] Intdir last call review of
> draft-ietf-ipwave-vehicular-networking-20
>
>
>
> Hi Pascal,
>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 3 Sep 2021 00:30:13 +0900

Hi Pascal,
I have reflected your comments on the revision:
https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-22

Though the text provided by you is excellent, it is long, so I place it on
Appendix B:
https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-22#appendix-B

In Section 5.1.3.  Routing, I explain RPL concisely along with pros and
cons:
https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-22#section-5.1.3

The changes with my some editings look like the following:
----------------------------------------------------------------------------------------------------------------------
5.1.3. Routing
...
RPL [RFC6550] defines a routing protocol for low-power and lossy networks,
which constructs and
maintains DODAGs optimized by an Objective Function (OF). A defined OF
provides route selection
and optimization within an RPL topology. A node in a DODAG uses DODAG
Information Objects (DIOs)
messages to discover and maintain the upward routes toward the root node.
Refer to Appendix B for
the detailed description of RPL for multihop V2X networking.
...
----------
Appendix B. Support of Multihop V2X Networking
...
RPL is primarily designed to minimize the control plane activity, which is
the relative amount of routing
protocol exchanges versus data traffic; this approach is beneficial for
situations where the power and
bandwidth are scarce (e.g., an IoT LLN where RPL is typically used today),
but also in situations of
high relative mobility between the nodes in the network (also known as
swarming, e.g., within a
variable set of vehicles with a similar global motion, or a variable set of
drones flying toward the same
direction).

To reduce the routing exchanges, RPL leverages a Distance Vector approach,
which does not need a
global knowledge of the topology, and only optimizes the routes to and from
the root, allowing
Peer-to-Peer (P2P) paths to be stretched. Although RPL installs its routes
proactively, it only maintains
them lazily, that is, in reaction to actual traffic, or as a slow
background activity. Additionally, RPL
leverages the concept of an objective function (called OF), which allows to
adapt the activity of the
routing protocol to use cases, e.g., type, speed, and quality of the
radios. RPL does not need converge,
and provides connectivity to most nodes most of the time. The default route
toward the root is
maintained aggressively and may change while a packet progresses without
causing loops, so the
packet will still reach the root. There are two modes for routing in RPL
such as non-storing mode and
storing mode. In non-storing mode, a node inside the mesh/swarm that
changes its point(s) of
attachment to the graph informs the root with a single unicast packet
flowing along the default route,
and the connectivity is restored immediately; this mode is preferable for
use cases where Internet
connectivity is dominant. On the other hand, in storing mode, the routing
stretch is reduced, for a
better P2P connectivity, while the Internet connectivity is restored more
slowly, during the time for
the DV operation to operate hop-by-hop. While an RPL topology can quickly
scale up and down and
fits the needs of mobility of vehicles, the total performance of the system
will also depend on how
quickly a node can form an address, join the mesh (including
Authentication, Authorization, and
Accounting (AAA)), and manage its global mobility to become reachable from
another node outside
the mesh.
...
----------------------------------------------------------------------------------------------------------------------

Thanks.

Best Regards,
Paul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 2 Sep 2021 15:49:16 +0000

You did well Paul, but I wonder if the reader of section 5.1 really cares about the guts of the protocols (DIO messages, who cares?) vs. what the protocol is optimized for.

I had the same feeling about the next paragraph where you describe 8505. While what you are saying is correct is that of interest for the reader?

The interesting piece IMHO is that 8505, as opposed to 4861,  is stateful and proactively installs the ND cache entries, which saves broadcasts and provides a deterministic presence information for IPv6 addresses”. This is what I’d like to see written there. For the RPL piece, if you want to summarize my text, please insist on the fact that it’s “DV, with lazy maintenance and stretched anisotropic routing, all designed to reduce the topological knowledge and routing state that needs to be exchanged. As a result, the routing protocol overhead is minimized, which allows either highly constrained stable networks or less constrained highly dynamic networks”.

From: Mr. Jaehoon Paul Jeong <[email-masked]>
Sent: jeudi 2 septembre 2021 17:30
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]; Last Call <[email-masked]>; [email-masked]; Russ Housley <[email-masked]>; CARLOS JESUS BERNARDOS CANO <[email-masked]>; Chris Shen <[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked]>
Subject: Re: [ipwave] Intdir last call review of draft-ietf-ipwave-vehicular-networking-20

Hi Pascal,

Though the text provided by you is excellent, it is long, so I place it on Appendix B:
https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-22#appendix-B

In Section 5.1.3.  Routing, I explain RPL concisely along with pros and cons:
https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-22#section-5.1.3

The changes with my some editings look like the following:
----------------------------------------------------------------------------------------------------------------------
5.1.3. Routing
...
RPL [RFC6550] defines a routing protocol for low-power and lossy networks, which constructs and
maintains DODAGs optimized by an Objective Function (OF). A defined OF provides route selection
and optimization within an RPL topology. A node in a DODAG uses DODAG Information Objects (DIOs)
messages to discover and maintain the upward routes toward the root node. Refer to Appendix B for
the detailed description of RPL for multihop V2X networking.
...
----------
Appendix B. Support of Multihop V2X Networking
...
RPL is primarily designed to minimize the control plane activity, which is the relative amount of routing
protocol exchanges versus data traffic; this approach is beneficial for situations where the power and
bandwidth are scarce (e.g., an IoT LLN where RPL is typically used today), but also in situations of
high relative mobility between the nodes in the network (also known as swarming, e.g., within a
variable set of vehicles with a similar global motion, or a variable set of drones flying toward the same
direction).

To reduce the routing exchanges, RPL leverages a Distance Vector approach, which does not need a
global knowledge of the topology, and only optimizes the routes to and from the root, allowing
Peer-to-Peer (P2P) paths to be stretched. Although RPL installs its routes proactively, it only maintains
them lazily, that is, in reaction to actual traffic, or as a slow background activity. Additionally, RPL
leverages the concept of an objective function (called OF), which allows to adapt the activity of the
routing protocol to use cases, e.g., type, speed, and quality of the radios. RPL does not need converge,
and provides connectivity to most nodes most of the time. The default route toward the root is
maintained aggressively and may change while a packet progresses without causing loops, so the
packet will still reach the root. There are two modes for routing in RPL such as non-storing mode and
storing mode. In non-storing mode, a node inside the mesh/swarm that changes its point(s) of
attachment to the graph informs the root with a single unicast packet flowing along the default route,
and the connectivity is restored immediately; this mode is preferable for use cases where Internet
connectivity is dominant. On the other hand, in storing mode, the routing stretch is reduced, for a
better P2P connectivity, while the Internet connectivity is restored more slowly, during the time for
the DV operation to operate hop-by-hop. While an RPL topology can quickly scale up and down and
fits the needs of mobility of vehicles, the total performance of the system will also depend on how
quickly a node can form an address, join the mesh (including Authentication, Authorization, and
Accounting (AAA)), and manage its global mobility to become reachable from another node outside
the mesh.
...
----------------------------------------------------------------------------------------------------------------------

Thanks.

Best Regards,
Paul

On Thu, Sep 2, 2021 at 3:49 PM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Paul

“

“

Otherwise, all good!

Take care,

Pascal

From: Mr. Jaehoon Paul Jeong <[email-masked]<mailto:[email-masked]>>
Sent: lundi 30 août 2021 15:12
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Last Call <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Russ Housley <[email-masked]<mailto:[email-masked]>>; CARLOS JESUS BERNARDOS CANO <[email-masked]<mailto:[email-masked]>>; skku-iotlab-members <[email-masked]<mailto:[email-masked]>>; Chris Shen <[email-masked]<mailto:[email-masked]>>; Mr. Jaehoon Paul Jeong <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ipwave] Intdir last call review of draft-ietf-ipwave-vehicular-networking-20

Hi Pascal,

Thanks.

Best Regards,
Paul

Dear authors

In summary:

Review:

Abstract

<snip>

1.  Introduction

transport a network?

<snip>

<snip>

2.  Terminology

<snip>

<snip>

3.  Use Cases

<snip>

“

<snip>

<snip>

by something like :

<snip>

<snip>

4.  Vehicular Networks

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

5.  Problem Statement

<snip>

DAD ?

5.1.  Neighbor Discovery

<snip>

 <snip>

 <snip>

<snip>

5.1.1.  Link Model

<snip>

<snip>

<snip>

<snip>

5.1.3.  Routing

5.2.  Mobility Management

<snip>

<snip>

the DAD is

  There is a

<snip>

<snip>

(rfc6583) ?

<snip>

<snip>

<snip>

                               This DAD can be used

<snip>

 This possibility

<snip>

Voila!

Keep safe;

Pascal

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Thu, 2 Sep 2021 20:29:41 +0200

Thanks a lot Pascal! This is extremely helpful.

Carlos

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 3 Sep 2021 04:23:11 +0000

All good Paul,

we’re done for this round. Good luck for the next steps!

Take care,

Pascal

Le 3 sept. 2021 à 05:22, Mr. Jaehoon Paul Jeong <[email-masked]> a écrit :

Hi Pascal,
Thanks for your help to improve this draft significantly.

I have included your suggested text in the revision (-23) as follows:
https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-23
----------------------------------------------------------------------------------------------------------------------------------------
Section 5.1.3. Routing
...
RPL [RFC6550] defines a routing protocol for low-power and
lossy networks, which constructs and maintains Destination-Oriented
Directed Acyclic Graphs (DODAGs) optimized by an Objective Function
(OF). A defined OF provides route selection and optimization within
an RPL topology. A node in a DODAG discovers and maintains the
upward routes toward the root node of the DODAG. RPL uses a Distance
Vector (DV) approach, with lazy maintenance and stretched anisotropic
routing. It is well-designed to reduce the topological knowledge and
routing state that needs to be exchanged. As a result, the routing
protocol overhead is minimized, which allows either highly
constrained stable networks or less constrained, highly dynamic
networks. Refer to Appendix B for the detailed description of RPL for
multihop V2X networking.

An address registration extension for 6LoWPAN (IPv6 over Low-Power
Wireless Personal Area Network) in [RFC8505] can support light-weight
mobility for nodes moving through different parents. [RFC8505], as
opposed to [RFC4861], is stateful and proactively installs the ND
cache entries, which saves broadcasts and provides a deterministic
presence information for IPv6 addresses. Mainly it updates the
Address Registration Option (ARO) of ND defined in [RFC6775] to
include a status field that can indicate the movement of a node and
optionally a Transaction ID (TID) field, i.e., a sequence number that
can be used to determine the most recent location of a node. Thus,
RPL can use the information provided by the Extended ARO (EARO)
defined in [RFC8505] to deal with a certain level of node mobility.
When a leaf node moves to the coverage of another parent node, it
should de-register its addresses to the previous parent node and
register itself with a new parent node along with an incremented TID.
----------------------------------------------------------------------------------------------------------------------------------------

If you are satisfied with this revision, could you update
the status of INTDIR Last Call Review into Ready?
https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/

Carlos and Erik,
If Pascal confirms the readiness of this draft,
let's move it out to the next step.

Thanks.

Best Regards,
Paul

On Fri, Sep 3, 2021 at 12:50 AM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
You did well Paul, but I wonder if the reader of section 5.1 really cares about the guts of the protocols (DIO messages, who cares?) vs. what the protocol is optimized for.

Cc: [email-masked]<mailto:[email-masked]>; Last Call <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Russ Housley <[email-masked]<mailto:[email-masked]>>; CARLOS JESUS BERNARDOS CANO <[email-masked]<mailto:[email-masked]>>; Chris Shen <[email-masked]<mailto:[email-masked]>>; Mr. Jaehoon Paul Jeong <[email-masked]<mailto:[email-masked]>>

Hi Pascal,

Thanks.

Best Regards,
Paul

“

“

Otherwise, all good!

Take care,

Pascal

Hi Pascal,

Thanks.

Best Regards,
Paul

Dear authors

In summary:

Review:

Abstract

<snip>

1.  Introduction

transport a network?

<snip>

<snip>

2.  Terminology

<snip>

<snip>

3.  Use Cases

<snip>

“

<snip>

<snip>

by something like :

<snip>

<snip>

4.  Vehicular Networks

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

5.  Problem Statement

<snip>

DAD ?

5.1.  Neighbor Discovery

<snip>

 <snip>

 <snip>

<snip>

5.1.1.  Link Model

<snip>

<snip>

<snip>

<snip>

5.1.3.  Routing

5.2.  Mobility Management

<snip>

<snip>

the DAD is

  There is a

<snip>

<snip>

(rfc6583) ?

<snip>

<snip>

<snip>

                               This DAD can be used

<snip>

 This possibility

<snip>

Voila!

Keep safe;

Pascal

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 3 Sep 2021 12:21:14 +0900

Hi Pascal,

Carlos and Erik,

Thanks.

Best Regards,
Paul

On Fri, Sep 3, 2021 at 12:50 AM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> You did well Paul, but I wonder if the reader of section 5.1 really cares
> about the guts of the protocols (DIO messages, who cares?) vs. what the
> protocol is optimized for.
>
>
>
> I had the same feeling about the next paragraph where you describe 8505.
> While what you are saying is correct is that of interest for the reader?
>
>
>
> The interesting piece IMHO is that 8505, as opposed to 4861,  is stateful
> and proactively installs the ND cache entries, which saves broadcasts and
> provides a deterministic presence information for IPv6 addresses”. This is
> what I’d like to see written there. For the RPL piece, if you want to
> summarize my text, please insist on the fact that it’s “DV, with lazy
> maintenance and stretched anisotropic routing, all designed to reduce the
> topological knowledge and routing state that needs to be exchanged. As a
> result, the routing protocol overhead is minimized, which allows either
> highly constrained stable networks or less constrained highly dynamic
> networks”.
>
>
>
> *Sent:* jeudi 2 septembre 2021 17:30
> *Cc:* [email-masked]; Last Call <[email-masked]>; [email-masked];
> Russ Housley <[email-masked]>; CARLOS JESUS BERNARDOS CANO <
> [email-masked]>; Chris Shen <[email-masked]>; Mr. Jaehoon Paul
> Jeong <[email-masked]>
> On Thu, Sep 2, 2021 at 3:49 PM Pascal Thubert (pthubert) <

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 3 Sep 2021 13:52:08 +0900

Pascal,
Thanks a lot for your help and confirmation.

Take care, too.

Best Regards,
Paul

On Fri, Sep 3, 2021 at 1:23 PM Pascal Thubert (pthubert) <[email-masked]>
wrote:

>> This is absolutely excellent. I’m very happy will all the changes and
>> your attached pdf made my life as a reviewer a lot simpler.
>>
>>
>>
>> The roots of my contribution to RPL are in vehicular networks, exactly
>> the use case you describe. Based on that experience (including some actual
>> test with NASA) I’d change the text above with:
>>
>>
>>
>>
>>
>> “
>>
>> To reduce the routing exchanges, RPL leverages a Distance Vector
>> approach, which does not need a global knowledge of the topology, and only
>> optimizes the routes to and from the root, allowing P2P paths to be
>> stretched. Although RPL installs its routes proactively, it only maintains
>> them lazily, in reaction to actual traffic, or as a slow background
>> activity. Additionally, RPL leverages the concept of an objective function,
>> which allows to adapt the activity of the routing protocol to the use case,
>> e.g., type, speed, and quality of the radios. RPL does not need converge,

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 3 Sep 2021 06:55:50 +0000

Hello Paul

Rereading a sentence I found it could be clarified at the next occasion. No need to publish a fix now 😊

The sentence is

“
                   A node in a DODAG discovers and maintains the
   upward routes toward the root node of the DODAG.  RPL uses a Distance
   Vector (DV) approach, with lazy maintenance and stretched anisotropic
   routing.

“

As I reread it, it seems to mean that the DODAG comes first and then the nodes discover and maintain the upwards routes.
The DODAG is indeed the coalescence of all upwards routes. Also, it is unclear that the sentence after refers to the downwards routes.

What about

“

   The RPL nodes uses an anisotropic Distance Vector (DV)approach to form

   a DODAG by discovering and aggressively maintaining the upward default route

   towards the root of the DODAG.  Downwards routes follow the same DODAG,

,  with lazy maintenance and stretched P2P routing in the so-called storing

   mode.

“

Keep safe;

Pascal

From: Mr. Jaehoon Paul Jeong <[email-masked]>
Sent: vendredi 3 septembre 2021 6:52
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: CARLOS JESUS BERNARDOS CANO <[email-masked]>; Erik Kline <[email-masked]>; [email-masked]; Last Call <[email-masked]>; [email-masked]; Russ Housley <[email-masked]>; Chris Shen <[email-masked]>; skku-iotlab-members <[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked]>
Subject: Re: [ipwave] Intdir last call review of draft-ietf-ipwave-vehicular-networking-20

Pascal,

Take care, too.

Best Regards,
Paul

On Fri, Sep 3, 2021 at 1:23 PM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
All good Paul,

Pascal

Le 3 sept. 2021 à 05:22, Mr. Jaehoon Paul Jeong <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Pascal,

Carlos and Erik,

Thanks.

Best Regards,
Paul

Hi Pascal,

Thanks.

Best Regards,
Paul

“

“

Otherwise, all good!

Take care,

Pascal

Hi Pascal,

Thanks.

Best Regards,
Paul

Dear authors

In summary:

Review:

Abstract

<snip>

1.  Introduction

transport a network?

<snip>

<snip>

2.  Terminology

<snip>

<snip>

3.  Use Cases

<snip>

“

<snip>

<snip>

by something like :

<snip>

<snip>

4.  Vehicular Networks

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

5.  Problem Statement

<snip>

DAD ?

5.1.  Neighbor Discovery

<snip>

 <snip>

 <snip>

<snip>

5.1.1.  Link Model

<snip>

<snip>

<snip>

<snip>

5.1.3.  Routing

5.2.  Mobility Management

<snip>

<snip>

the DAD is

  There is a

<snip>

<snip>

(rfc6583) ?

<snip>

<snip>

<snip>

                               This DAD can be used

<snip>

 This possibility

<snip>

Voila!

Keep safe;

Pascal

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 3 Sep 2021 16:00:44 +0900

Pascal,
Sure, I will reflect your suggested text on the next revision.

Thanks.

Best Regards,
Paul

2021년 9월 3일 (금) 오후 3:56, Pascal Thubert (pthubert) <[email-masked]>님이
작성:

> As I reread it, it seems to mean that the DODAG comes first and then the
> nodes discover and maintain the upwards routes.
>
> The DODAG is indeed the coalescence of all upwards routes. Also, it is
> unclear that the sentence after refers to the downwards routes.
>
>
>
> What about
>
>
>
> “
>
> *Sent:* vendredi 3 septembre 2021 6:52
> *Cc:* CARLOS JESUS BERNARDOS CANO <[email-masked]>; Erik Kline <
> [email-masked]>; [email-masked]; Last Call <[email-masked]>;
> [email-masked]; Russ Housley <[email-masked]>; Chris Shen <
> [email-masked]>; skku-iotlab-members <
> [email-masked]>; Mr. Jaehoon Paul Jeong <
> [email-masked]>
> On Fri, Sep 3, 2021 at 1:23 PM Pascal Thubert (pthubert) <
> --
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department Head
Department of Computer Science and Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 9 Sep 2021 10:20:29 +0200

I am not disagreeing with the changes of the draft that PAscal proposed 
and authors integrated.

Howeve, I need to make a few remarks, just for clarification.

Le 02/09/2021 à 08:49, Pascal Thubert (pthubert) a écrit :
> “
>
> RPL is primarily designed to minimize the control plane activity, that 
> is the relative amount of routing protocol exchanges vs. data traffic;
>

We must not forget that RPL was designed in the RoLL WG; RoLL means 
Routing over Low Power and Lossy Links.  RPL was pushed forward very 
much by an application domain which relates to the electricity counters 
at home.  We should remember that, because we discussed it extensively 
at the time.  There was much frustration.  After all that discussion, 
now we come back to say that actually, no, it was not so?

In that sense, it is strange to say that RPL is 'primarily' designed for 
a goal (minimize control plane activity) which differs from the goals of 
the RoLL WG.

This situation is very much like when we have a tool (RPL) and try to 
use it for many different purposes whose scopes are different.

Cars are not low-power.  Cars have very high energy available and very 
many horses as power (horse-power).

Cars do not use lossy links any more than regular WiFi is a lossy link.

Certainly, when experimenting with car networks many packets get lost, 
and many errors show up.  But there are so many other causes for that to 
happen, than what a protocol can deal with: the things that happen have 
to do in many cases with human factors like the working conditions 
(programmers are not sitted comfortably at a desk, but are uncomfortably 
sit in cars with small screens small keyboards); then there are so many 
intermediary layers of protocols which might fail, and also the 
reporting which often fails.  These things generate a majority of events 
that one might take for a 'lossy network'.

> this approach is beneficial for situations where the power and 
> bandwidth are scarce (e.g., an IoT LLN where RPL is typically used 
> today), but also in situations of high relative mobility between the 
> nodes in the network (aka swarming, e.g., within a variable set of 
> vehicles with a similar global motion, or a toon of drones).
>

Car networks do not need arbitrary mobility.  Their mobility patterns 
are very restricted.  It is not brownian movements.

For example, cars move on ways along pre-determined paths.  There might 
be convoys, and sliding lanes of cars, there might be intersections 
controlled by traffic lights; human reaction (in the order of 1 or 2 
seconds, or more) is what makes for dynamicity in car networks; that 
time (seconds delay) is very very high compared to the latency of modern 
wireless media (e.g. 802.11bd with below milli-second latencies).  
Generally speaking it is  a very orderly movement.

Yes, we are impressed with the speed of cars, and imagine that for these 
speeds the communication protocols might not cope with.  But one has to 
consider _relative_ speeds (e.g. a car following another one is 
practically stationary with respect to it), and one has to consider the 
speed of the communication  medium which is the speed of light.

Think that even a launch of a rocket carrying tons of payload at 30.000 
km/h vertically still sends live video we can enjoy seeing over the 
Internet today.  There is no need of new protocol for that kind of 
mobility, and still the dynamicity aspect (speed) is very very extreme; 
it is probably the highest speeds one can achieve  on Earth.

Trying to make 'universal' protocols that work well in a a wide range of 
mobility and dynamicity is a too high objective.  One can try, yes, but 
does it succeed in deployment?

Alex

> approach, which does not need a global knowledge of the topology, and 
> only optimizes the routes to and from the root, allowing P2P paths to 
> be stretched. Although RPL installs its routes proactively, it only 
> maintains them lazily, in reaction to actual traffic, or as a slow 
> background activity. Additionally, RPL leverages the concept of an 
> objective function, which allows to adapt the activity of the routing 
> protocol to the use case, e.g., type, speed, and quality of the 
> radios. RPL does not need converge, and provides connectivity to most 
> nodes most of the time. The default route towards the Root is 
> maintained aggressively and may change while a packet progresses 
> without causing loops, so the packet will still reach the root. In 
> non-storing mode, a node inside the mesh/swarm that changes its 
> point(s) of attachment to the graph informs the root with a single 
> unicast packet the flows along the default route, and the connectivity 
> is restored immediately; this mode is preferable for use cases where 
> internet connectivity is dominant. OTOH, in storing mode, the routing 
> stretch is reduced, for a better P2P connectivity, while the internet 
> connectivity is restored more slowly, time for the DV operation to 
> operate hop-by-hop. While a RPL topology can quickly scale up and down 
> and fits the needs of mobility of vehicles, the total performance of 
> the system will also depend on how quickly a node can form an address, 
> join the mesh (including AAA), and manage its global mobility to 
> become reachable from outside the mesh.
>
> “
>
> Otherwise, all good!
>
> Take care,
>
> Pascal
>
> [email-masked]; [email-masked]; 
> Russ Housley <[email-masked]>; CARLOS JESUS BERNARDOS CANO 
> <[email-masked]>; skku-iotlab-members 
> <[email-masked]>; Chris Shen 
> <[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked]>
> <https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-21>
>
> On Fri, Jun 18, 2021 at 4:42 PM Pascal Thubert via Datatracker 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Reviewer: Pascal Thubert
>     Review result: Not Ready
>
>     Dear authors
>
>     In summary:
>
>     https://datatracker.ietf.org/doc/html/rfc3963#section-2
>     <https://datatracker.ietf.org/doc/html/rfc3963#section-2> and
>     that’s a reference
>     you can use normatively.
>
>     <snip>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/its>
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 9 Sep 2021 10:30:32 +0200

Le 09/09/2021 à 10:20, Alexandre Petrescu a écrit :
> vehicles with a similar global motion, or a toon of drones).

For the 'toon of drones' - we came up with the word 'flightooning' in a 
small group of people I talk to.  These 'flightoons' use a very coherent 
internal structure.  It is 'figé', which means the drones dont  move 
with respect to each other and fly together as a single unit.

These flightoons do move in 3 dimensions, but the relative speed of a 
drone with respect to the other is 0, and the group follows 
pre-determined paths; its altitude parameter does take values between 0 
and 300meters for a length of maybe a few hundred meters).  The 
flightooning use-case is simpler than the sliding lanes of convoys 
(mainly on a 2 dimensional road, and just a small variation in altitidue 
like a few tens of meters along a few kilometers - the 'pente', max. 15 
degrees for most advanced tanks) on the road where there is variable 
speed (ach lane has a different speed).  These parameters are well 
known.  They might constitute what some people consider an 'ODD' (an 
Operational Design Domain), a set of limits within which the respective 
mobile entities are guaranteed a certain level of safety at a certain 
level of automation (L1..L4, SAE).

The communication system in a toon of drones, or a 'flightoon', might 
not need to use RPL, which is designed for electricity counters at home.

Alex

> For example, cars move on ways along pre-determined paths.  There 
> might be convoys, and sliding lanes of cars, there might be 
> intersections controlled by traffic lights; human reaction (in the 
> order of 1 or 2 seconds, or more) is what makes for dynamicity in car 
> networks; that time (seconds delay) is very very high compared to the 
> latency of modern wireless media (e.g. 802.11bd with below 
> milli-second latencies).  Generally speaking it is  a very orderly 
> movement.
>
> Yes, we are impressed with the speed of cars, and imagine that for 
> these speeds the communication protocols might not cope with.  But one 
> has to consider _relative_ speeds (e.g. a car following another one is 
> practically stationary with respect to it), and one has to consider 
> the speed of the communication  medium which is the speed of light.
>
> Think that even a launch of a rocket carrying tons of payload at 
> 30.000 km/h vertically still sends live video we can enjoy seeing over 
> the Internet today.  There is no need of new protocol for that kind of 
> mobility, and still the dynamicity aspect (speed) is very very 
> extreme; it is probably the highest speeds one can achieve  on Earth.
>
> Trying to make 'universal' protocols that work well in a a wide range 
> of mobility and dynamicity is a too high objective.  One can try, yes, 
> but does it succeed in deployment?
>
> Alex
>
>
>> unicast packet the flows along the default route, and the 
>> connectivity is restored immediately; this mode is preferable for use 
>> cases where internet connectivity is dominant. OTOH, in storing mode, 
>> the routing stretch is reduced, for a better P2P connectivity, while 
>> the internet connectivity is restored more slowly, time for the DV 
>> operation to operate hop-by-hop. While a RPL topology can quickly 
>> scale up and down and fits the needs of mobility of vehicles, the 
>> total performance of the system will also depend on how quickly a 
>> node can form an address, join the mesh (including AAA), and manage 
>> its global mobility to become reachable from outside the mesh.
>>
>> “
>>
>> Otherwise, all good!
>>
>> Take care,
>>
>> Pascal
>>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 09 Sep 2021 13:10:42 -0400

{I'm not clued into all of this thread}

Alexandre Petrescu <[email-masked]> wrote:
    > and many errors show up.  But there are so many other causes for that
    > to happen, than what a protocol can deal with: the things that happen
    > have to do in many cases with human factors like the working conditions
    > (programmers are not sitted comfortably at a desk, but are
    > uncomfortably sit in cars with small screens small keyboards); then
    > there are so many intermediary layers of protocols which might fail,
    > and also the reporting which often fails.  These things generate a
    > majority of events that one might take for a 'lossy network'.

Before I knew that ITS was a thing (back around 2010), I was driving to
Boston from Ottawa alone. In the winter.  I don't drive much in general.
I had put my audio-book CD on the counter, but left it at home, so I had many
hours alone to think about mobile networks in automobiles.

    > controlled by traffic lights; human reaction (in the order of 1 or 2

In the dark January blizzard in upstate Vermont, I was thinking a lot about
convoys of cars with connectivity among themselves, but no connectivity out.
Safe travel distances in those conditions mean ideally being far enough apart
to not be able to see tail lights.   Being able to get warnings of slowdowns
ahead for four or five cars ahead of me would be great.
But, I considered that the killer app was probably chat among the passengers.

RPL has a whole slew of "secured" versions of every message.  These have
proved uninteresting to current LLNs: too expensive to do asymmetric crypto
given energy budgets, and lack of deployed certificates.
Automobiles don't have either problem.
And they do have mutual distrust, and we can't do a "network-wide" PSK,
so we need to use the asymmetric versions of the RPL routing code.
I'm not aware of ISIS/OSPF having that feature.
BGP4 has it (RPKI), but I'm not convinced BGP4 has the right properties for a
convey.

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 11 Sep 2021 23:33:09 +0200

Hi Alex,

 I think the draft should consider more than one standard and more than one
networking protocol.

On Thu, Sep 9, 2021 at 10:20 AM Alexandre Petrescu <
[email-masked]> wrote:

> the relative amount of routing protocol exchanges vs. data traffic;
>
>
> Routing over Low Power and Lossy Links.  RPL was pushed forward very much
> by an application domain which relates to the electricity counters at
> home.  We should remember that, because we discussed it extensively at the
> time.  There was much frustration.  After all that discussion, now we come
> back to say that actually, no, it was not so?
>
> In that sense, it is strange to say that RPL is 'primarily' designed for a
> goal (minimize control plane activity) which differs from the goals of the
> RoLL WG.
>
 RPL is primarily for LLNs only.

> This situation is very much like when we have a tool (RPL) and try to use
> it for many different purposes whose scopes are different.
>
> Certainly, when experimenting with car networks many packets get lost, and
> many errors show up.  But there are so many other causes for that to
> happen, than what a protocol can deal with: the things that happen have to
> do in many cases with human factors like the working conditions
> intermediary layers of protocols which might fail, and also the reporting
> which often fails.  These things generate a majority of events that one
> might take for a 'lossy network'.
>
> this approach is beneficial for situations where the power and bandwidth
> are scarce (e.g., an IoT LLN where RPL is typically used today), but also
> in situations of high relative mobility between the nodes in the network
> (aka swarming, e.g., within a variable set of vehicles with a similar
> global motion, or a toon of drones).
>
>
> Car networks do not need arbitrary mobility.  Their mobility patterns are
> very restricted.  It is not brownian movements.
>
> For example, cars move on ways along pre-determined paths.  There might be
> convoys, and sliding lanes of cars, there might be intersections controlled
> by traffic lights; human reaction (in the order of 1 or 2 seconds, or more)
> is what makes for dynamicity in car networks; that time (seconds delay) is
> very very high compared to the latency of modern wireless media (e.g.
> 802.11bd with below milli-second latencies).  Generally speaking it is  a
> very orderly movement.
>
> consider _relative_ speeds (e.g. a car following another one is practically
> stationary with respect to it), and one has to consider the speed of the
> communication  medium which is the speed of light.
>
> mobility, and still the dynamicity aspect (speed) is very very extreme; it
> is probably the highest speeds one can achieve  on Earth.
>

I agree it is  strange to use RPL in mobility networks, it is for LLNs. So
I advise the author to delete any indication that RPL is used for mobility
nets, however, for mobility IETF can use MANET routing. There may be a use
case of RPL inside one vehicle, but not between vehicles while moving.
Overall,  I think the draft needs modifications to use-cases and focus its
details on the network topology, architecture, standards & protocols,
challenges, but not to go into specifications. It will be important that
the draft includes the type of links and frequencies used in the cases or
standards.

best regards
 AB

Alex
> <[email-masked]>
> *To:* Pascal Thubert (pthubert) <[email-masked]> <[email-masked]>
> *Cc:* [email-masked]; Last Call <[email-masked]>
> <[email-masked]>; [email-masked];
> [email-masked]; Russ Housley <[email-masked]> <[email-masked]>;
> CARLOS JESUS BERNARDOS CANO <[email-masked]> <[email-masked]>;
> skku-iotlab-members <[email-masked]>
> <[email-masked]>; Chris Shen <[email-masked]>
> <[email-masked]>
> its mailing [email-masked]://www.ietf.org/mailman/listinfo/its
>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 16 Sep 2021 22:05:28 +0900

Hi Abdussalam,
Thanks for your opinion.

The IPWAVE PS Draft has been made and updated by IPWAVE WG since October
2016, that is, for the last 5 years.

As the editor of this draft, I think that the coauthors as contributors and
I have reflected the opinions of IPWAVE WG on this draft.

Let's see the opinions from the IESG.

Thanks.

Best Regards,
Paul

On Sun, Sep 12, 2021 at 6:42 AM Abdussalam Baryun <
[email-masked]> wrote:

> Hi Alex,
>
>  I think the draft should consider more than one standard and more than
> one networking protocol.
>
>> seconds, or more) is what makes for dynamicity in car networks; that time
>> (seconds delay) is very very high compared to the latency of modern
> I agree it is  strange to use RPL in mobility networks, it is for LLNs.
> So  I advise the author to delete any indication that RPL is used for
> mobility nets, however, for mobility IETF can use MANET routing. There may
> be a use case of RPL inside one vehicle, but not between vehicles while
> moving.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 17 Sep 2021 18:41:21 +0000

Paul, it has been a long time since I have looked but are the AERO and OMNI technologies
still well represented in this document? Those works are done now, and should be cited
here as candidate solutions.

Thanks - Fred

From: its [mailto:[email-masked]] On Behalf Of Mr. Jaehoon Paul Jeong
Sent: Thursday, September 16, 2021 6:05 AM
To: Abdussalam Baryun <[email-masked]>
Cc: Alexandre Petrescu <[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked]>; its <[email-masked]>
Subject: [EXTERNAL] Re: [ipwave] Intdir last call review of draft-ietf-ipwave-vehicular-networking-20

EXT email: be mindful of links/attachments.

Hi Abdussalam,
Thanks for your opinion.

The IPWAVE PS Draft has been made and updated by IPWAVE WG since October 2016, that is, for the last 5 years.

As the editor of this draft, I think that the coauthors as contributors and I have reflected the opinions of IPWAVE WG on this draft.

Thanks.

Best Regards,
Paul

On Sun, Sep 12, 2021 at 6:42 AM Abdussalam Baryun <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alex,

 I think the draft should consider more than one standard and more than one networking protocol.

On Thu, Sep 9, 2021 at 10:20 AM Alexandre Petrescu <[email-masked]<mailto:[email-masked]>> wrote:

I am not disagreeing with the changes of the draft that PAscal proposed and authors integrated.

Howeve, I need to make a few remarks, just for clarification.
Le 02/09/2021 à 08:49, Pascal Thubert (pthubert) a écrit :
“
RPL is primarily designed to minimize the control plane activity, that is the relative amount of routing protocol exchanges vs. data traffic;

We must not forget that RPL was designed in the RoLL WG; RoLL means Routing over Low Power and Lossy Links.  RPL was pushed forward very much by an application domain which relates to the electricity counters at home.  We should remember that, because we discussed it extensively at the time.  There was much frustration.  After all that discussion, now we come back to say that actually, no, it was not so?

In that sense, it is strange to say that RPL is 'primarily' designed for a goal (minimize control plane activity) which differs from the goals of the RoLL WG.
 RPL is primarily for LLNs only.

This situation is very much like when we have a tool (RPL) and try to use it for many different purposes whose scopes are different.

Cars are not low-power.  Cars have very high energy available and very many horses as power (horse-power).

Certainly, when experimenting with car networks many packets get lost, and many errors show up.  But there are so many other causes for that to happen, than what a protocol can deal with: the things that happen have to do in many cases with human factors like the working conditions (programmers are not sitted comfortably at a desk, but are uncomfortably sit in cars with small screens small keyboards); then there are so many intermediary layers of protocols which might fail, and also the reporting which often fails.  These things generate a majority of events that one might take for a 'lossy network'.
this approach is beneficial for situations where the power and bandwidth are scarce (e.g., an IoT LLN where RPL is typically used today), but also in situations of high relative mobility between the nodes in the network (aka swarming, e.g., within a variable set of vehicles with a similar global motion, or a toon of drones).

Car networks do not need arbitrary mobility.  Their mobility patterns are very restricted.  It is not brownian movements.

For example, cars move on ways along pre-determined paths.  There might be convoys, and sliding lanes of cars, there might be intersections controlled by traffic lights; human reaction (in the order of 1 or 2 seconds, or more) is what makes for dynamicity in car networks; that time (seconds delay) is very very high compared to the latency of modern wireless media (e.g. 802.11bd with below milli-second latencies).  Generally speaking it is  a very orderly movement.

Yes, we are impressed with the speed of cars, and imagine that for these speeds the communication protocols might not cope with.  But one has to consider _relative_ speeds (e.g. a car following another one is practically stationary with respect to it), and one has to consider the speed of the communication  medium which is the speed of light.

Think that even a launch of a rocket carrying tons of payload at 30.000 km/h vertically still sends live video we can enjoy seeing over the Internet today.  There is no need of new protocol for that kind of mobility, and still the dynamicity aspect (speed) is very very extreme; it is probably the highest speeds one can achieve  on Earth.

Trying to make 'universal' protocols that work well in a a wide range of mobility and dynamicity is a too high objective.  One can try, yes, but does it succeed in deployment?

I agree it is  strange to use RPL in mobility networks, it is for LLNs. So  I advise the author to delete any indication that RPL is used for mobility nets, however, for mobility IETF can use MANET routing. There may be a use case of RPL inside one vehicle, but not between vehicles while moving.
Overall,  I think the draft needs modifications to use-cases and focus its details on the network topology, architecture, standards & protocols, challenges, but not to go into specifications. It will be important that the draft includes the type of links and frequencies used in the cases or standards.

best regards
 AB

Alex

Otherwise, all good!

Take care,

Pascal

From: Mr. Jaehoon Paul Jeong <[email-masked]><mailto:[email-masked]>
Sent: lundi 30 août 2021 15:12
To: Pascal Thubert (pthubert) <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Last Call <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Russ Housley <[email-masked]><mailto:[email-masked]>; CARLOS JESUS BERNARDOS CANO <[email-masked]><mailto:[email-masked]>; skku-iotlab-members <[email-masked]><mailto:[email-masked]>; Chris Shen <[email-masked]><mailto:[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked]><mailto:[email-masked]>
Subject: Re: [ipwave] Intdir last call review of draft-ietf-ipwave-vehicular-networking-20

Hi Pascal,

Thanks.

Best Regards,
Paul

Dear authors

In summary:

Review:

Abstract

<snip>

1.  Introduction

transport a network?

<snip>

<snip>

2.  Terminology

<snip>

<snip>

3.  Use Cases

<snip>

“

<snip>

<snip>

by something like :

<snip>

<snip>

4.  Vehicular Networks

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

<snip>

5.  Problem Statement

<snip>

DAD ?

5.1.  Neighbor Discovery

<snip>

 <snip>

 <snip>

<snip>

5.1.1.  Link Model

<snip>

<snip>

<snip>

<snip>

5.1.3.  Routing

5.2.  Mobility Management

<snip>

<snip>

the DAD is

  There is a

<snip>

<snip>

(rfc6583) ?

<snip>

<snip>

<snip>

                               This DAD can be used

<snip>

 This possibility

<snip>

Voila!

Keep safe;

Pascal

its mailing list

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 17 Sep 2021 22:58:43 +0200

Hi Paul,

Thank you for your efforts, so do you mean now it is pushed to IESG? if yes
then ok its good news for me and the WG.
We I don't need other work to be pushed as primarily in this WG-doc.

comments below,

> Thanks for your opinion.

good comments and suggests, I would prefer that you commented on it.

> 2016, that is, for the last 5 years.

yes 5 year for informational..... and I am following, so no problem we need
to push it by replies to get it through,

>
> As the editor of this draft, I think that the coauthors as contributors
> and I have reflected the opinions of IPWAVE WG on this draft.
>

not sure I understand your statement. I want that we progress in the
process for all docs (it is informational draft). Therefore, I supported
Alex's comment because reviewer has suggested some things that do not
reflect any of this WG.

Regards
AB

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Sat, 18 Sep 2021 10:08:14 +0900

Hi Fred,
OMNI is mentioned in the Appendices in the revision as a possible solution:
https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-23

Since this draft is a problem statement, possible solutions (e.g., OMNI and
RPL) are
discussed in the Appendices according to the Intdir reviewer Pascal Thubert.

Thanks.

Best Regards,
Paul

On Sat, Sep 18, 2021 at 3:41 AM Templin (US), Fred L <
[email-masked]> wrote:

> *From:* its [mailto:[email-masked]] *On Behalf Of *Mr. Jaehoon Paul
> Jeong
> *Sent:* Thursday, September 16, 2021 6:05 AM
> *To:* Abdussalam Baryun <[email-masked]>
> *Cc:* Alexandre Petrescu <[email-masked]>; Mr. Jaehoon Paul
> Jeong <[email-masked]>; its <[email-masked]>
> *Subject:* [EXTERNAL] Re: [ipwave] Intdir last call review of

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Sat, 18 Sep 2021 10:15:25 +0900

Hi Abdussalam,
I tried to address the comments of Pascal Thubert as an Intdir reviewer
during the IESG last call, especially RPL.
I discussed the pros and cons of RPL for vehicular networks in the revision.

This draft is waiting for the Writeup of our AD Erik Kline for the IESG
review.

Let's see the feedback from the IESG and reflect their comments
on the draft.

Thanks.

Best Regards,
Paul

On Sat, Sep 18, 2021 at 6:07 AM Abdussalam Baryun <
[email-masked]> wrote:

> Hi Paul,
>
> Thank you for your efforts, so do you mean now it is pushed to IESG? if
> yes then ok its good news for me and the WG.
> yes 5 year for informational..... and I am following, so no problem we
> need to push it by replies to get it through,
>
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 30 Sep 2021 11:34:09 +0200

Hi,

About draft-ietf-ipwave-vehicular-networking-23.

As a side note, I would like to make a few comments on this draft with 
respect to its platooning discussion.

I am not suggesting modifications to the draft, but as more time passes 
I think it is necessary to consider that the domain evolves.

This draft is generally a good overview of vehicular networking.  But as 
the draft advances, the domain of activities performed outside the draft 
advances too.  In particular, in the discussions about V2V and 
platooning several significant evolvements were realized since the first 
parts of the draft were written.

For example, the 'multi-brand truck' platooning in Europe ('ENSEMBLE') 
was demonstrated on 7 vehicles just a few days ago; earlier it was just 
3 trucks.  They use a mixture of bouncing signal (radar, camera) ACC, a 
newly proposed ETSI CAM extensions messages, but no IP; they also use a 
single antenna on the truck.

Other platooning or convoy demonstrators were performed in recent years: 
one used 3 small automated vehicles in 'AUTOPILOT' with IPv6 and RTMAPS, 
entirely new (non-CAM) TCP payloads of IPv6 messages (non-CAM), and 
distinct front-rear antennas; it also used enhancements to RA messages 
for route propagation in a linear topology.  Another 'AUTOPILOT' 
demonstrator used 2 or 3 Toyotas using IP on cellular in order to 'form' 
the convoy; that communicated 'V2V' but a more complex 'V2V': at link 
layer it is V2I2V but at app layer it is V2V (car to cloud and back to 
car with a polling protocol).

The descriptions of V2V and platooning in this draft do not mention the 
fact that a car might have distinct front-rear antennas.   In Figure 4: 
Multihop Internetworking between Two Vehicle Networks, one can see a 
single roof antenna in each car.  That is a possibility, and not the 
only one.  In other platoons there are two antennas in each car.

Further, the draft doest not give reference to something else than than 
the US Truck Platooning of 'PATH'.  That is a very good earlier 
reference, but there is more references to give now, e.g. 'ENSEMBLE' and 
'AUTOPILOT'.  I have an URL handy for ENSEMBLE 
https://platooningensemble.eu/library/presentations but for 'AUTOPILOT' 
I cant really suggest an URL; the reason I cant suggest an URL for 
AUTOPILOT is not that it does not exist, but the manner in which it 
exists illustrates a signficant failure of the Certificate Authority 
concept as we know it (Let's Encrypt is good, but fails in some browsers).

Alex

Le 18/09/2021 à 03:15, Mr. Jaehoon Paul Jeong a écrit :
> This draft is waiting for the Writeup of our AD Erik Kline for the 
> IESG review.
>
> On Sat, Sep 18, 2021 at 6:07 AM Abdussalam Baryun 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Paul,
>
>     Thank you for your efforts, so do you mean now it is pushed to
>     IESG? if yes then ok its good news for me and the WG.
>     On Thu, Sep 16, 2021 at 3:06 PM Mr. Jaehoon Paul Jeong
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi Abdussalam,
>         Thanks for your opinion.
>
>
>         The IPWAVE PS Draft has been made and updated by IPWAVE WG
>         since October 2016, that is, for the last 5 years.
>
>
>     yes 5 year for informational..... and I am following, so no
>     problem we need to push it by replies to get it through,
>
>
>         As the editor of this draft, I think that the coauthors as
>         contributors and I have reflected the opinions of IPWAVE WG on
>         this draft.
>
>
>     not sure I understand your statement. I want that we progress in
>     the process for all docs (it is informational draft). Therefore, I
>     supported Alex's comment because reviewer has suggested some
>     things that do not reflect any of this WG.
>
>     Regards
>     AB
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 30 Sep 2021 11:51:24 +0200

I agree with your comments, however, I got a reply from authors as they
talk on behave of WG, which I think it can be ok for the progress because
it is only informational draft, but your comments and mine and another
participant just recently sent, suggested some kind of adding-value to our
WG-draft while it is going through the submission to IESG process. In this
situation of IESG process, these comments should be involving with the WG
AD,  so I hope he can help us and reply to our comments/situations, or that
he considers/hears it.

For many of those reasons, I think we need a reply from the WG chair or AD.

Best Regards
AB

On Thu, Sep 30, 2021 at 11:35 AM Alexandre Petrescu <
[email-masked]> wrote:

> I am not suggesting modifications to the draft, but as more time passes I
> think it is necessary to consider that the domain evolves.
>
> advances too.  In particular, in the discussions about V2V and platooning
> several significant evolvements were realized since the first parts of the
> draft were written.
>
> For example, the 'multi-brand truck' platooning in Europe ('ENSEMBLE') was
> demonstrated on 7 vehicles just a few days ago; earlier it was just 3
> trucks.  They use a mixture of bouncing signal (radar, camera) ACC, a newly
> proposed ETSI CAM extensions messages, but no IP; they also use a single
> antenna on the truck.
>
> distinct front-rear antennas; it also used enhancements to RA messages for
> route propagation in a linear topology.  Another 'AUTOPILOT' demonstrator
> used 2 or 3 Toyotas using IP on cellular in order to 'form' the convoy;
> that communicated 'V2V' but a more complex 'V2V': at link layer it is V2I2V
> but at app layer it is V2V (car to cloud and back to car with a polling
> protocol).
>
> Multihop Internetworking between Two Vehicle Networks, one can see a single
> roof antenna in each car.  That is a possibility, and not the only one.  In
> other platoons there are two antennas in each car.
>
> the US Truck Platooning of 'PATH'.  That is a very good earlier reference,
> but there is more references to give now, e.g. 'ENSEMBLE' and 'AUTOPILOT'.
> I have an URL handy for ENSEMBLE
> https://platooningensemble.eu/library/presentations but for 'AUTOPILOT' I
> cant really suggest an URL; the reason I cant suggest an URL for AUTOPILOT
> is not that it does not exist, but the manner in which it exists
> illustrates a signficant failure of the Certificate Authority concept as we
> know it (Let's Encrypt is good, but fails in some browsers).
>
> Alex
>
>