Re: [ipwave] Last Call: <draft-ietf-ipwave-vehicular-networking-20.txt> (IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases) to Informational RFC

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

> -----Original Message-----
> From: ipv6 <[e-mail]> On Behalf Of Brian E Carpenter
> Sent: mardi 15 juin 2021 5:25
> To: Erik Kline <[e-mail]>; [e-mail]
> Cc: 6MAN <[e-mail]>; [e-mail]; draft-ietf-ipwave-vehicular-
> [e-mail]; Carlos Bernardos <[e-mail]>; IETF-Announce <ietf-
> [e-mail]>; [e-mail]
> 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, 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.

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 <[e-mail]> 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 [e-mail] mailing lists by 2021-06-28. Exceptionally,
> >> comments may be sent to [e-mail] 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
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------