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 23:28 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 6DC403A0E38; Wed, 2 Mar 2022 15:28:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.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_DNSWL_HI=-5, 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 rz3feycRjjyg; Wed, 2 Mar 2022 15:28:10 -0800 (PST)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 B00213A0E18; Wed, 2 Mar 2022 15:28:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 222NS6ur027754; Wed, 2 Mar 2022 18:28:07 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1646263687; bh=Jt7vSG/24bfa5fUcpGV9ZgsbVSrTOAODX+GOfxaHEg4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=mISekcflM+2TjUtCHxZus/Lcb7hs8oKANvajM7j8byITq9wJ4T8ugQEfiebzk2H++ Gt/j3XS4qds3PyK8YU3iVSEzWtMCG5xM411X/1xmGIP8QNxjXv9Q+GIDZNM3bzFc/U IAmQ+I1bbX2/Rs2U7PlUnLf6kBsV76iJtyr5yRLZ+p92OyjRct/uXJPplle5Do4HXY aIzgHc8wrwm61ySq8r1/GnPTftllRfsYCPx4kgzwa+5Bp3LnF2QlgINE0d9HUirERu WwvOiVcMQwG6uUdW0kVgXaSyxSZ43uHxwO7o/MFq09PTC2AOcmgq5ObROfOlttNFKk iqbTHTiJfqMwg==
Received: from XCH16-07-10.nos.boeing.com (xch16-07-10.nos.boeing.com [144.115.66.112]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 222NS4Rk027741 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 2 Mar 2022 18:28:04 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-10.nos.boeing.com (144.115.66.112) 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 15:28:03 -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 15:28:03 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
CC: "int-dir@ietf.org" <int-dir@ietf.org>, "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+NEH0Nan0B0QAczVJAAEnzzrAABgdnOQADhlhg
Date: Wed, 02 Mar 2022 23:28:02 +0000
Message-ID: <ce308c053cdd4bbea827137c458652b9@boeing.com>
References: <66cb2374027048319d05e214c6731f95@boeing.com> <CO1PR11MB48819D5910656A2F2095687FD8029@CO1PR11MB4881.namprd11.prod.outlook.com> <ddbc2f1956974b41b1914c2e65d1b8a0@boeing.com> <96D2A7E0-BAAA-4710-A3FD-DC9FFE319615@cisco.com>
In-Reply-To: <96D2A7E0-BAAA-4710-A3FD-DC9FFE319615@cisco.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: 9A4F7C8E63424F002DCBC26F8CCC72D22EF96702EFC454A006D3067530BCEAC42000: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/SlWq-F3ehMF6sScOB5H__KDm_tk>
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 23:28:16 -0000

Pascal, thanks - the only obvious hiccup is that I failed to specify that the OMNI overlay RS/RA
messaging is unicast-only (or anycast) and never broadcast/multicast. So, it is efficient and only
between a vehicle and its nearest IP-RSU without disturbing any other vehicles or IP-RSUs. I am
willing to let the dust settle on this for now and see what edits Paul can come up with.

Fred

> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
> Sent: Wednesday, March 02, 2022 1:43 PM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: int-dir@ietf.org; last-call@ietf.org; draft-ietf-ipwave-vehicular-networking.all@ietf.org; its@ietf.org
> Subject: [EXTERNAL] Re: [ipwave] Intdir telechat review of draft-ietf-ipwave-vehicular-networking-27
> 
> EXT email: be mindful of links/attachments.
> 
> 
> 
> Hello Fred
> 
> Please see below
> 
> > Le 2 mars 2022 à 21:06, Templin (US), Fred L <Fred.L.Templin@boeing.com> a écrit :
> >
> > 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.
> 
> All good; we are missing the specifications of statistical characteristics that would allow to lawfully ignore DAD. Without that there can be
> no claim that DAD is not needed even for ULAs.
> 
> RFC 8505 models every node to node as IP P2P even in transit networks. DAD for link local need only to be asserting that pair since that pair
> is the link. It is thus instantaneous.
> 
> For prefixes owned by a RSU, using RFC 8605 the RSU is garant for the uniqueness of addresses in that prefix so then again we have a DAD
> guarantee.
> 
> We could derive something similar for you ULA so they can be decoupled from a GUA  MNP, eg the MNP can be private / temporary ULA
> like the RPL visitor network.
> 
> 
> >
> >> 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.
> >
> 
> The OMNI addresses are /128 from the same /64 ULA prefix. You route between them in the underlay. So you underlay is an MLSN. By
> definition.
> 
> 
> >>> 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.
> 
> Exactly. This is how Wi-Sun deploys RPL. Another way of seeing it is that what you do at L2 with spanning tree or L2R is now done at L3.
> 
> >
> >> 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.
> 
> It can only be guaranteed unique by the OMNI interface if the prefix is uniquely used for OMNI. There are less random bits in the prefix than
> in an IID. So collision on the prefix ULA used by another node for non OMNI  are more likely to happen than on a random IID in any normal
> network. But ok the chances to duplicate that address are negligible and should be neglected.
> 
> 
> >
> >> 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."
> 
> It is. This is why we build IP link as P2P regardless of the L2 link.
> 
> IOW We decouple the L2 broadcast domain the L3 link and L3 subnet.
> 
> A world of opportunities for IPv6.
> >
> > 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?
> >
> 
> It is, as it is for you since inception. Part of my 95%
> 
> >>> 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?
> >
> 
> Yes that is MLSN.
> 
> >> 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?
> 
> 
> If the VANET can leverage the links between RSUs then it becomes more than a MANET. That is again an opportunity not an issue.
> 
> >
> >> 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.).
> >
> Ok
> 
> >> 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.
> 
> If you’re sure that addresses with that prefix are only formed with GuA prefixes as IID that works fine for sure. The privacy guys will not love
> you for it but it’s another story…
> 
> >
> >>> 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).
> 
> Yes that’s certainly one model for hierarchical network.  Broadcasting RS/RA in the overlay will cost like OSPF flooding. Surely you want to
> optimize that at least like OLSR did.
> 
> If you look at it the RPL DIO is also flooded and transports the RA options you need like PIO. The little plus is that it forms the routing
> DODAG for the same price and RS are not flooded.
> 
> RPL does not require any semantics in the address and does not expose the MNP if you want it private, at the expense of an additional
> encapsulation for reaching globally.
> 
> But that is fine pro con discussion; the bottom line is that we route inside the network in a fashion that is independent of routing outside.
> 
> >
> >>> 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.
> 
> Actually you can autoconf the IID as long as the RSU can confirm that you formed a unique one. That’s the summary of the functionality in
> RFC 8505. Either way works but if folks prefer autoconf then RFC 8505 is the best friend of your design…
> 
> >
> >>> 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.
> >
> 
> Indeed…
> 
> Pascal
> > 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