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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Wed, 02 March 2022 20:06 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBEA3A0826; Wed, 2 Mar 2022 12:06:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvCC41x3Znol; Wed, 2 Mar 2022 12:06:09 -0800 (PST)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7BDC3A07F7; Wed, 2 Mar 2022 12:06:08 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 222K63dd015851; Wed, 2 Mar 2022 15:06:06 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1646251566; bh=z0+JeyCkxaXCE9m8mT0yApch8nf9BvXl8IabfKO9bGM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=CcYeXmPdPUMTKWj9sqVjWvTAsSMPHMI1KiXV7f/z4DycQwQyz/P4dhiXNXTl5ib4Z zT0jw5scwc0MOtJfVOJk+ggPffBiHVETd4pGUrkOS7cyvW6S0reQXW3ctsHbfhfdGW BLsOBwMe5w7K/q/Kw54UIzFxJqfClJifR/sV3D1XZG6DODhHFYJJT6RrlMVDjPBGlv CZ5cv/yCkKK92rGy1Blitw5EXeK9mbKUqLLqWtC75VNFCxqDcr0pkmxIxl8WVabDyG 9SzVxHz0IXZqEDvKx1rebythySSzhNELWfsZMgmociETBRj4mJq21FlCCIfq1PoiEV 3AXroQEtKki4w==
Received: from XCH16-07-08.nos.boeing.com (xch16-07-08.nos.boeing.com [144.115.66.110]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 222K5rrs015431 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 2 Mar 2022 15:05:53 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-08.nos.boeing.com (144.115.66.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.18; Wed, 2 Mar 2022 12:05:52 -0800
Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.2375.018; Wed, 2 Mar 2022 12:05:52 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "int-dir@ietf.org" <int-dir@ietf.org>
CC: "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-ipwave-vehicular-networking.all@ietf.org" <draft-ietf-ipwave-vehicular-networking.all@ietf.org>, "its@ietf.org" <its@ietf.org>
Thread-Topic: [ipwave] Intdir telechat review of draft-ietf-ipwave-vehicular-networking-27
Thread-Index: Adgsy2XvleSKXiVJSP+NEH0Nan0B0QAczVJAAEnzzrA=
Date: Wed, 02 Mar 2022 20:05:52 +0000
Message-ID: <ddbc2f1956974b41b1914c2e65d1b8a0@boeing.com>
References: <66cb2374027048319d05e214c6731f95@boeing.com> <CO1PR11MB48819D5910656A2F2095687FD8029@CO1PR11MB4881.namprd11.prod.outlook.com>
In-Reply-To: <CO1PR11MB48819D5910656A2F2095687FD8029@CO1PR11MB4881.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 0589EECFAAF92C822D66FCA58C5B719755FC4B007359CB1FAEE90B86412BA4072000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/9zo0CzQW5Ok_KT-1vLvtBWfbzDA>
Subject: Re: [ipwave] Intdir telechat review of draft-ietf-ipwave-vehicular-networking-27
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Mar 2022 20:06:15 -0000

OK Pascal, I am back again - see below for responses:

Fred

> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
> Sent: Tuesday, March 01, 2022 12:43 AM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>; int-dir@ietf.org
> Cc: last-call@ietf.org; draft-ietf-ipwave-vehicular-networking.all@ietf.org; its@ietf.org
> Subject: RE: [ipwave] Intdir telechat review of draft-ietf-ipwave-vehicular-networking-27
> 
> Hello Fred
> 
> > -----Original Message-----
> > From: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> > Sent: lundi 28 février 2022 19:09
> > To: Pascal Thubert (pthubert) <pthubert@cisco.com>; int-dir@ietf.org
> > Cc: last-call@ietf.org; draft-ietf-ipwave-vehicular-
> > networking.all@ietf.org; its@ietf.org
> > Subject: RE: [ipwave] Intdir telechat review of draft-ietf-ipwave-
> > vehicular-networking-27
> >
> > Pascal, I have no issues with what you said below, and I assume that since
> > you referenced some of my comments you are OK with the rest of the ones
> > that I sent to Paul?
> >
> 
> That would be optimistic. Some of your points are non-technical and Paul is the editor, he should make the decision.
> I reacted to the technical points I agreed with to add pressure on Paul to act on them.
> Then again I agreed more with the technical issue you raised and your proposed resolution than with your exact wording, and then again
> Paul is the editor anyway.

Exact wording is not critical for me. One exception is that the term "Bring Your Own Address
(BYOA) is not sitting well with me currently - does it simply mean a statistically-unique self-
generated address that is highly unlikely to conflict with an address chosen by another node
within the same local network routing region? That is what is currently done using the
"Temporary Address" facility based on ULAs configured according to the OMNI addressing
architecture. I am sure there may be other examples that would have similar statistically
uniqueness properties, but Temporary ULAs is how OMNI would prefer to see it worded.

> But first and foremost, I see OMNI as an abstract interface for non-broadcast networks, and MLSN as a network that can be reached via
> OMNI. I see no opposition but highly complementary stuff.

I agree with complimentary. However, from a higher layer perspective we should
be more and more seeing OMNI as a new adaptation layer for the Internet moreso than
focusing on the lower-level details of NBMA, MLSN, etc. The MLSNs are at the mobile
edges of the network, but the OMNI adaptation layer provides an overlay that extends
over the edges. So, the underlay network details are important, but so is the higher-level
overlay perspective.

> > I have a discussion point however - the business of multilink subnet. I
> > used to think the concept was inherently evil, but now that I have a
> > deeper understanding of the problem statement I am beginning to see some
> > possibilities.
> 
> If you pick all the addresses of your MANET from the same /64 you have a MLSN.

OK, that would be fine for me. For example, a /64 such as fd12:3456:789a:bcde::/64
would make for a fine shared prefix for a MANET where all MANET nodes receive a
/128 within that /64 - correct? But then, according to RFC5889, each MANET node
would use a /128 prefix length in its MANET-local routing exchanges instead of a /64;
correct? If true, and if that is what you are calling a MLSN, then that is fine for me.

> Take RPL: deployed in the smartgrid, it is a MLSN.
> Deployed between cars with a mobile network prefix (MNP) each, it's more of a MANET of MNPs.

With the OMNI addressing architecture, you get both MLSN and MNP information
in a single IPv6 address. So, let's say the MLSN /64 is fd12:3456:789a:bcde::/64 and
a mobile node's MNP is 2001:db8:1:2::/4, then the OMNI address for that particular
MLSN would be written as:

   fd12:3456:789a:bcde:2001:db8:1:2/128

It is guaranteed unique within the MLSN so the subnet can operated without DAD.
And, it includes both MLSN and MNP information so you get two pieces of routing
information for the price of one.

> Even a hub and spoke like Bluetooth is an MLSN. The idea behind it is to decouple the L3 abstraction from the L2 connectivity and build
> select P2P IP links over whatever L2 gives you. For all I can see, this is exactly what you're also describing, and it's not evil, it's a world of
> opportunities. In fact, 6LoWPAN explicitly inherits that model from MANET.

Right, but it all comes down to the link model. If the link model you have in mind is
according to RFC5889 where it says:

   "Link-level connectivity is generally qualified as undetermined when
   it is unplanned and/or time-varying in character.  Ad hoc networks
   are typical examples of networks with undetermined link-level
   connectivity."

then that is fine with me, and we can operate that as an MLSN all day long given
an appropriate subnet-local routing service and the application of /128 prefix
lengths. Does that match the model you have in mind?

> > Am I correct that the document assumes that each IP-RSU
> > will be the head-end of a "subnet" consisting of a VANET in which all
> > vehicles configure an address from a common IPv6 prefix? So, for example,
> > IP-RSU1 could be the head-end of a subnet 2001:db8:1:2::/64 and IP-RSU2
> > could be the head-end of a subnet 2001:db8:3:4::/64 - correct?
> 
> One or more RSUs can share the same /64. If there's only one RSU per /64 this is a hub and spoke (like a BSS at L2). If multiple RSUs, you
> have to route between them for the host addresses in the prefix, (like an ESS will bridge).

OK, then that is even better and even more well aligned with OMNI. If you are OK with
multiple RSUs all sharing the same /64, then the way OMNI differentiates the RSUs is by
giving them each a unique "interface identifier" within the (shared) /64. Is that what
you mean?

> 2 cars, even connected to the same RSU, many not be in sight of one another. So the model is that each car has a P2P IP link with the RSU
> and the RSU relays.

This is where there might be a slight philosophical divergence - a [MV]ANET can be thought
of as a loosely-knit grouping of (multiple) P2P links or, alternatively, it could be said that all
[MV]ANET nodes connect to a (singular) link with undetermined link-level connectivity per
RFC5889. But, does the distinction matter?

> OSPF called that P2MP as opposed to NBMA which was non broadcast full mesh and did not need routing inside. This is where we have to
> agree on terms, since you only mention NBMA.

No, the NBMA is only intended in the overlay - I should have made that more clear.
In underlying [MV]ANETs, it can be based on whatever the underlying network routing
services entail (RPL, MANET, etc.).

> In a Wi-Fi ESS/BSS, the RSU is an Access point and it does bridging. Outside of the context of a BSS in OCB), all you have is L3 and this is
> called a MLSN, and the RSU is a router. So the goal is the exact same as BSS/ESS. Obtain an address that is externally reachable,
> topologically correct, and that does not need renumbering as you move within the MLSN.

OMNI does that by having the RSU (or, Proxy/Server in OMNI terms) assign each node
a /128 unique address within the MLSN /64 when the node enters the [MV]ANET.

> > But, these subnets are not related to the IPv6 MNPs that are on-board the
> > individual vehicles and so would not be used as end system addresses for
> > global-scope comms; correct?
> 
> Not related is correct. For global comm, partially correct. You can have multiple MNPs. ULA MNPs are useful for local comms between cars
> and relaying in V2V2I, but we also want MNPs that can be globally reachable with NEMO. E.g., a device connected to the Wi-Fi inside the
> car (or train) may want to connect to the internet in which case that MNP is GUA.
> 
> More details:
> 
> For V2V, we have a model where the cars have "visitors" MNPs that are ULA and short lived. This helps for anonymizing the MNP owner.
> Neighbor vehicles can form addresses from the "visitors" MNP when in range using anonymized IIDs, just like they can from RSUs. This
> forms an IP link and you can route along those links, including source routing. This was the original model for RPL.
> 
> Then there's a home MNP that is GUA (and BYOP) for NEMO purpose. And the router address inside that prefix is BYOA if you want to see it
> that way. This is for sourcing packets to the internet as opposed to relaying as above.
> 
> Using RPL you can route along the "visitors" MNP between cars to reach the AP of the parking lot, this is how you can do V2V2I. If you inject
> that MNP in the RPL then NEMO needs a single tunnel to the parking lot using the parking lot as CoA. If you hide it for privacy reasons, you
> need to take your CoA from your own "visitors" MNP, and that's 2 tunnels. OMNI could simplify that.
> 
> We called that MANEMO long ago, coupling MANET for V2V with NEMO for V2I, in order to solve the famous "nested nemo" problem.

With AERO/OMNI, each vehicle would have one or more GUA MNPs. The RSU would then
authorize the vehicle to use the MNPs as the lower 64 bits of an address configured from
the MLSN /64 - again, two pieces of routing information tucked inside a singular address.
And, this would be based on IPv6 RS/RA messaging between the vehicle and RSU in the
OMNI overlay (i.e., as opposed to in the [MV]ANET underlay).

> > So then, what is the purpose of the IP-RSU
> > based multilink subnet? Is it to simply group vehicles according to their
> > current IP-RSU affiliation?
> 
> The vehicle is reachable from the internet with that address while in range. As the doc says, this can be short lived, if the vehicle is moving
> fast. My car averages < 20mph in practice, and is parked most if its time, so it's useful.
> 
> > Is it to inform the VANET routing protocol to
> > only exchange routing information with other vehicles that share a common
> > IP-RSU based subnet prefix? Or, are there other benefits that I am not
> > understanding?
> 
> Having an address that is routable between RSUs is also useful, say along a road. If the RSUs share the same /64 it is still a MLSN, and this
> set gives you a scope for the lookups/advertisements.

All good.

> Now if the car has a BYOA and you extend your VANET using the RSUs along a road, someone has to define how far the advertisements and
> lookups propagate, which is how far this car is reachable from another. That works too, just that the MLSN automates it.
> 
> About BYOA and DAD. There are less random bits in a ULA prefix than in an IID. OTOH there are more random bits in an ULA address since
> you randomize both. The question behind is how many randomized bit in the 128 are enough to claim that DAD is not needed.

If the "BYOA" you are referring to is one and the same as what OMNI calls a "Temporary ULA"
then OMNI is providing (40 + 64) = 104 randomly-assigned bits. That, plus the fact that the
Temporary ULAs are just that (temporary) and get replaced right away with RSU-delegated
addresses within the MLSN obviate any need for DAD.

> > If we see benefits for maintaining IP-RSU based multilink subnets, then we
> > can do that also based on ULA addresses according to the OMNI addressing
> > architecture.
> > The ULAs would then include IP-RSU multilink subnet information in the
> > upper 64 bits and include MNP-based IPv6 global scope addressing
> > information in the lower
> > 64 bits. The OMNI addressing architecture would have to be adapted
> > slightly to make that happen, but before I go there can we have a
> > discussion of the perceived benefits of the IP-RSU based multilink subnet?
> >
> 
> I'd like to see that. The integration of local and global reachability (ULA vs GUA, MANET vs NEMO) does not appear to be fully solved at this
> time.

Maybe have a look at the OMNI addressing architecture to see how it can couple
ULA and GUA information so that a single IPv6 address can carry both MLSN and
MNP information. Other than that, I see many more similarities than differences
in the way we are both articulating the problem space.

Thanks - Fred

> Keep safe;
> 
> Pascal
> >
> > > -----Original Message-----
> > > From: its [mailto:its-bounces@ietf.org] On Behalf Of Pascal Thubert
> > > via Datatracker
> > > Sent: Monday, February 28, 2022 5:57 AM
> > > To: int-dir@ietf.org
> > > Cc: last-call@ietf.org;
> > > draft-ietf-ipwave-vehicular-networking.all@ietf.org; its@ietf.org
> > > Subject: [EXTERNAL] [ipwave] Intdir telechat review of
> > > draft-ietf-ipwave-vehicular-networking-27
> > >
> > > EXT email: be mindful of links/attachments.
> > >
> > >
> > >
> > > Reviewer: Pascal Thubert
> > > Review result: Ready with Issues
> > >
> > > I am an assigned INT directorate reviewer for
> > > draft-ietf-ipwave-vehicular-networking-27. These comments were written
> > > primarily for the benefit of the Internet Area Directors. Document
> > > editors and
> > > shepherd(s) should treat these comments just like they would treat
> > > comments from any other IETF contributors and resolve them along with
> > > any other Last Call comments that have been received. For more details
> > > on the INT Directorate, see
> > > https://datatracker.ietf.org/group/intdir/about/
> > > <https://datatracker.ietf.org/group/intdir/about/>.
> > >
> > > Based on my review, the document IS ready to go to IETF Last Call and
> > > therefore CAN be forwarded to the IESG.
> > >
> > > I find the document well written, well referenced, and very
> > > informative. It fits the general goal of use-cases and problem statement
> > publication.
> > >
> > > The following are other issues I found with this document that SHOULD
> > > be corrected before publication:
> > >
> > > Fig 1 and section 4.1 show a “Corresponding Node”. Not sure where the
> > > term comes from, in NMIP and NEMO it is “Correspondent Node”  see and
> > > refer to RFC 4885.
> > >
> > > About
> > > Section 3.1: “
> > >    To support applications of these V2I use cases, the required
> > >    functions of IPv6 include IPv6-based packet exchange, transport-layer
> > >    session continuity, and secure, safe communication between a vehicle
> > >    and an infrastructure node (e.g., IP-RSU) in the vehicular network.
> > >
> > > “
> > > Section 3.2: “   To support applications of these V2I use cases, the
> > required
> > >    functions of IPv6 include IPv6-based packet exchange, transport-layer
> > >    session continuity, and secure, safe communication between a vehicle
> > >    and an infrastructure node (e.g., IP-RSU) in the vehicular network.
> > > ”
> > > Section 3.3:
> > > “
> > >    To support applications of these V2X use cases, the required
> > >    functions of IPv6 include IPv6-based packet exchange, transport-layer
> > >    session continuity, and secure, safe communication between a vehicle
> > >    and a pedestrian either directly or indirectly via an IP-RSU.
> > >
> > > “
> > > Each time, the text could clarify what goes in “packet exchange” since
> > > as written that seems to refer to data plane while the problem for IP
> > > is mostly control plane. e.g., the problem of discovering adjacent
> > > peers (addresses,
> > > networks) should be listed there shouldn’t it? Addressing is an topic
> > > of interest as well (BYO Address/Prefix vs. obtain a local address,
> > > how that relates with DAD and global connectivity). The doc discusses
> > > that heavily (around 5.1) and then there’s the discussion in 4.3 on ND
> > > variations and
> > > (MANET) NHDP, that must happen before IPv6 packets can be exchanged.
> > >
> > > As a hint, a suggestion can be:
> > > “
> > > … functions of IPv6 include IPv6 communication enablement with
> > > neighborhood discovery and IPv6 address management, reachability with
> > > adapted network models and routing methods, transport-layer … “
> > >
> > > Section 3.2
> > >
> > > Fred said ‘
> > > 3) Section 3.2, change the paragraph beginning: "The existing IPv6
> > > protocol must be augmented through protocol changes..."
> > > to:
> > > "The existing IPv6 protocol must be augmented either through protocol
> > > changes or by including a new adaptation layer in the architecture
> > > that efficiently maps IPv6 to a diversity of link layer technologies.
> > > Augmentation is necessary to support wireless multihop V2I
> > > communications in a highway where RSUs are sparsely deployed, so a
> > > vehicle can reach the wireless coverage of an RSU through the multihop
> > data forwarding of intermediate vehicles."
> > > ‘
> > >
> > > I agree that the document omits V2V2I completely. This is true in
> > > Fred’s highway case, but true also in a simple parking lot to share
> > > Wi-Fi access when the AP is too far. In the MIPv6 family we called
> > > that nested NEMO. The problem statement of nested NEMO is RFC 4888. I
> > > believe you need to provide a minimum of hint that V2V2I exists and
> > > for the lack of more reference you can search “nested NEMO”.
> > >
> > > Note that the early RPL was a solution for nested NEMO and interworked
> > > with NEMO. It has been tested successfully by NASA at their Glenn
> > > Center but I do not think something was published at the time, so no
> > ref.
> > >
> > > Note that I also agree with Fred’s point on 3.3. Maybe you can make it
> > > more verbose but in each case there’s a need to indicate that V2A2B
> > > can exist and needs future attention, even if it is a harder problem.
> > >
> > >
> > > Section 4.1:
> > > “
> > > In
> > >    this case, a handover for Vehicle2 needs to be performed by either a
> > >    host-based mobility management scheme (e.g., MIPv6 [RFC6275] … … “
> > > Section 4.2:
> > >
> > > “
> > >   Existing network architectures, such as the network architectures of
> > >    PMIPv6 [RFC5213] …
> > > “
> > >
> > > I see you have a reference to NEMO in the introduction, but this is
> > > where the reference makes the most sense and it is missing, next to
> > PMIPv6.
> > >
> > > It is easy to confuse network-based mobility (which is PMIPv6 vs.
> > > MIPv6, and is
> > > MIPv4 anyway) and network mobility, which is the case of a car that
> > > has a /64 inside and has to handle mobility for the /64.
> > >
> > > Indeed NEMO is the MIPv6 for networks (a mobile prefix inside the car
> > vs.
> > > MIP/PMIP which is a host address moving) and vehicles where a main use
> > > case for it. PMIPv6 is a variation of MIPv6 that distributes the roles
> > > differently for the lack of support by end devices, but does not route
> > for a mobile prefix.
> > > Network-based does not mean “mobile network”, and then you often call
> > > the mobile network a moving network, again per RFC 4885.
> > >
> > > For the latter, please stick to IETF terminology of “mobile network”
> > > as in RFC 3963, that will help the reader. I suggest you reference RFC
> > > 3963 here, and add RFC 4888 for completeness.
> > >
> > > Section 4.1:
> > >
> > > “
> > >   Alternatively, mobile nodes
> > >    can employ a "Bring-Your-Own-Addresses (BYOA)" technique using their
> > >    own IPv6 Unique Local Addresses (ULAs) [RFC4193] over the wireless
> > >    network, which does not require the messaging (e.g., Duplicate
> > >    Address Detection (DAD)) of IPv6 Stateless Address Autoconfiguration
> > >    (SLAAC) [RFC4862].
> > > “
> > > Again listing Bring your own prefix a well as address would improve
> > > completeness. A typical car has a mobile prefix inside.
> > >
> > > Section 4.2:
> > >
> > > “
> > > OMNI can support the
> > > “
> > >
> > > Suggest “OMNI is designed to support” unless there’s an actual
> > reference?
> > >
> > > Section 4.3
> > > Fred says “
> > > Section 4.3, final paragraph, there is no reason to cite as examples
> > > all RFC variants of the OLSR protocol and all extensions of the DLEP
> > > protocol - pick one (or at most 2) RFCs for each. Also, it is
> > > important to state that standard OSPF routing has been optimized to
> > > support MANET applications. Suggested
> > > rewrite: "...which serves MANET routing protocols such as the
> > > different versions of Optimized Link State Routing Protocol (OLSR)
> > > [RFC3626][RFC7181], Open Shortest Path First (OSPF) derivatives (e.g.,
> > > [RFC5614]) and the Dynamic Link Exchange Protocol (DLEP) [RFC8175] with
> > its extensions."
> > >
> > > “
> > > I agree. Maybe mention that there are V2V use case with a fixed set of
> > > cars
> > > (platooning) and others with variable neighborhood (parking lot, on
> > > the road), and the optimum solution may vary.
> > >
> > > Section 5:
> > >
> > > “is 72 seconds” looks precise though in fact it is very rough. Could
> > > say “in the order of a minute”. Same for V2V, 36s.
> > >
> > > Section 5.1.1
> > >
> > > “off-link”
> > >
> > > That terminology does not really exist. All we have is “not-onlink”.
> > >
> > > Section 5.2
> > >
> > > “There is nonnegligible
> > >    control overhead to set up and maintain routes to such a tunnel home
> > >    over the VANET.”
> > >
> > > There again a link to RFC 4888
> > >
> > > “Vehicles can use the TCC as their Home Network having a home agent
> > >    for mobility management as in MIPv6 [RFC6275] and PMIPv6 [RFC5213],”
> > >
> > > add “and NEMO [RFC 3963]”
> > >
> > > Appendix A: Mentions OMNI but fails to document real world implemented
> > > protocols such as DLEP which abstract the radio modem over ethernet
> > >
> > > The following are minor issues (typos, misspelling, minor text
> > > improvements) with the document:
> > >
> > > Section 5.1:
> > > “
> > >    This merging and partitioning should be considered for the
> > >    IPv6 ND such as IPv6 Stateless Address Autoconfiguration (SLAAC)
> > >    [RFC4862].
> > > “
> > > “
> > > they may not communicate with each other not in one
> > >    hop in the same
> > >
> > > “
> > > I can understand but the language seems incorrect. Also Fred says:
> > > ‘
> > > change: "they need to be configured with a link-local IPv6 address or
> > > a global
> > > IPv6 address" to: "they need to be configured with link-local,
> > > unique-local and/or global IPv6 addresses"
> > >
> > > ‘
> > > I mostly agree but then, those addresses are not necessarily
> > > configured. Maybe just says that they need the addresses.
> > >
> > > Section 6.1
> > >
> > > “the DAD”: we usually do not have the “the”. This appears throughout.
> > >
> > >
> > >
> > > _______________________________________________
> > > its mailing list
> > > its@ietf.org
> > > https://www.ietf.org/mailman/listinfo/its