I want to thank you for the message and take advantage of it to reply below:
Le 15/06/2021 à 08:31, Pascal Thubert (pthubert) a écrit :
-----Original Message----- From: ipv6 <ipv6-bounces@xxxxxxxx> On
Behalf Of Brian E Carpenter Sent: mardi 15 juin 2021 5:25 To: Erik
Kline <ek.ietf@xxxxxxxxx>; last-call@xxxxxxxx Cc: 6MAN
<6man@xxxxxxxx>; its@xxxxxxxx; draft-ietf-ipwave-vehicular-
networking@xxxxxxxx; Carlos Bernardos <cjbc@xxxxxxxxxx>;
IETF-Announce <ietf- announce@xxxxxxxx>; ipwave-chairs@xxxxxxxx
Subject: Re: Last Call:
<draft-ietf-ipwave-vehicular-networking-20.txt> (IPv6 Wireless
Access in Vehicular Environments (IPWAVE): Problem Statement and
Use Cases) to Informational RFC
Thanks for the heads-up, Erik.
This text at
https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-
vehicular-networking-20#page-9
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.
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, Brian; what became RPL was first demonstrated at the NASA
Glenn center doing video transmission from a car roaming at L3 (in
combination with NEMO) on Cisco prototype routers (in the PC104
format). RFC 9010 combines RPL with RFC 8505 which is already
discussed in rfc8691. I know from actual experience that we can build
a solid solution for V2V and V2I using those components,
With respect to V2V solution: me too I know from practical experience
that we can build an IPv6-based solution to maintain inter-distance,
speed, angle, etc. between automated automobiles in a platoon. A video
of an earlier trial with 3 automated automobiles and 2 V2V subnets shows
such a demo where IPv6 is used between vehicles without infrastructure
assistance, with IPv6 packets on OCB. This is the URL of the video
https://www.youtube.com/watch?v=32in-Lq9ezA
That V2V mechanism and demo works great, but it has an issue in that it
is a pure internal product: it runs on an internal test track, only one
organisation sits in each car (even if there are multiple organisations
involved), so the interoperability is very low. Moreover, only LL and
ULA addresses are being used. This means they are disconnected from the
Internet. The Internet connection of these automated automobiles is on
4G with IPv4. IPv6 Internet for automobiles is impossible because of
the 64 limit.
Recently I am identifying another, similar demo of V2V platoon without
infrastructure in Spain where, again, the same situation with internal
demo is happening. It's just that it is another site, other
organisations. But still, that too has this 'internal' characteristic
of being disconnected from the Internet. A 'limited domain' in IETF speak.
The necessity would be to find an interoperability crossing point where
a couple or more distinct organisations would need to interoperate. A
sort of a need to plug together two distinct 'limited domains'.
Using a same brand of vehicles does not help very much, even if one
could in theory put distinct software and hardware in each vehicle of a
same brand.
This is probably more likely to happen in vehicles of distinct brands
(e.g. a Toyota to talk to a Ford), or maybe distinct models of a same
brand (e.g. the brand Renault carries a TomTom computer in earlier
models and an LG computer in more recent models; so two cars of a same
brand would need to interoperate).
So, if it is possible to identify such a need of interop situation of
V2V it would be great.
One should be aware that in search of such a crossing point there are
dragons at some places. For example some manufacturers state clearly
they will use one single technology exclusively (e.g. Mercedes and Ford
will only use 5G, or C-V2X, or similar), while other car manufacturers
go the other route (VW to use only ITS-G5, or similar). So, one should
not propose to a Mercedes to talk to a VW, or to a Ford to talk to a
Toyota, as this might risk to upset people. However, it leaves the
doors open for discussion for some manufacturers, though.
probably with a modernized version of the routing headers we used at
the time (see
https://datatracker.ietf.org/doc/html/draft-thubert-6man-reverse-routing-header),
probably based on SRv6.
We could talk about the technology we like most, yes.
Alex
Here the document seems to be mixing solution with problem. Note that
I have no clue on how well OMNI applies in that space, maybe it does
very well. I guess I'm missing a high level resource that explains
exactly what it does vs. what it abstracts. I'm concerned that the
FF02 multicast illusion (that is only abstracted at L3 and is not
implemented at L2) could happen here again.
At this point I became confused about the purpose of the document.
The Abstract says
This document discusses the problem statement and use cases of
IPv6-based vehicular networking
In fact, most of section 4 seems to be a draft architecture of a
solution.
5. Problem Statement
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.
That's a big leap. But the rest of section 5 seems to get back to
solution design.
So I am left puzzled about what would happen next if this draft
becomes an RFC. Do the authors expect 6man to work on the issues
they've raised? I'm not sure they match 6man's limited charter
("not chartered to develop major changes or additions to the IPv6
specifications").
Interesting; I would have thought that the traditional steps of
problem statement and applicability statement of existing work could
be expected from IPWAVE too. I believe the group could find that a
targeted combination of existing RFCs solves the problem. But they
could also decide that they want to progress AERO/OMNI like HOMENET
suggested to progress BABEL.
But first of all, the IETF last call should validate that this
document is indeed a problem statement and that it leaves the
solution space open.
Keep safe;
Pascal
Regards Brian Carpenter
On 15-Jun-21 13:07, Erik Kline wrote:
+6man, since there are many statements about IPv6 work in this
document.
One thing of note: in the time after this document was WGLC'd,
6man held an adoption call on OMNI that did not result in
adoption [OMNI]. There are at two places where this text
appears:
"The existing IPv6 protocol must be augmented through the
addition of an OMNI interface..."
These statements should probably be revised (or removed).
-Erik
[OMNI]
https://mailarchive.ietf.org/arch/msg/ipv6/s1S49EYPThX34Gowu4ExPgFb32k
/
On Mon, Jun 14, 2021 at 7:02 AM The IESG
<iesg-secretary@xxxxxxxx> wrote:
The IESG has received a request from the IP Wireless Access in
Vehicular Environments WG (ipwave) to consider the following
document: - 'IPv6 Wireless Access in Vehicular Environments
(IPWAVE):
Problem
Statement and Use Cases'
<draft-ietf-ipwave-vehicular-networking-20.txt> as
Informational RFC
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send substantive
comments to the last-call@xxxxxxxx mailing lists by 2021-06-28.
Exceptionally, comments may be sent to iesg@xxxxxxxx instead.
In either case, please retain the beginning of the Subject line
to allow automated sorting.
Abstract
This document discusses the problem statement and use cases of
IPv6-based vehicular networking for Intelligent Transportation
Systems (ITS). The main scenarios of vehicular communications
are vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I),
and vehicle-to-everything (V2X) communications. First, this
document explains use cases using V2V, V2I, and V2X networking.
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 for IPv6-based vehicular networking.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networki
ng/
No IPR declarations have been submitted directly on this I-D.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@xxxxxxxx Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list ipv6@xxxxxxxx Administrative
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list ipv6@xxxxxxxx Administrative
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
