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

"Templin (US), Fred L" <> Mon, 28 February 2022 18:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06E5C3A12C8; Mon, 28 Feb 2022 10:09:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Status: No, score=-2.106 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_BLOCKED=0.001, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id grS6ZIWl6x0h; Mon, 28 Feb 2022 10:09:33 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E9C013A12BB; Mon, 28 Feb 2022 10:09:32 -0800 (PST)
Received: from localhost (localhost []) by (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 21SI9Upk015923; Mon, 28 Feb 2022 13:09:31 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=boeing-s1912; t=1646071771; bh=Xtb5ldWKGhyQQKbdKeDt/ItZ7xmrzDTU23Sc/7h+v/4=; h=From:To:CC:Subject:Date:From; b=HccZEgwszZUTnbMCLfMaVNzOfZkxERI4CqmcRhCeb1bbl1tnEM31pOYae6uFBlKz6 b00rWkVm0ZtozEhK2tYrcNmoRzMKGnl7NOkwQ3upoOmJIclRlkhd4/E807f+FHgWrl B0XGeQDKgc74jCdOkPaVsV4SCGIMLUyAHEyBQy5PZ0UPSNSc1jrdPN9AKwdIiDrD5H 5du6u56TCtWEWMOVXWz3BIhVdvN01/a4qt9efcNlF+yCkxZzDdbU4tM16smxd+AmM6 /XufD5XL7Epc1sEXSXUJKBZ5B7lJeXPLyXjLFc+5hlHBaT4DshKoldb1tIz6yCTS3i rYDqQvmjis9yg==
Received: from ( []) by (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 21SI9F8v015735 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Feb 2022 13:09:15 -0500
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.18; Mon, 28 Feb 2022 10:09:14 -0800
Received: from ([fe80::e065:4e77:ac47:d9a8]) by ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.2375.018; Mon, 28 Feb 2022 10:09:14 -0800
From: "Templin (US), Fred L" <>
To: Pascal Thubert <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: [ipwave] Intdir telechat review of draft-ietf-ipwave-vehicular-networking-27
Thread-Index: Adgsy2XvleSKXiVJSP+NEH0Nan0B0Q==
Date: Mon, 28 Feb 2022 18:09:14 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: 8123CCAF46B274F0BF4681464B98BDBB31E3596C4747D9F249DC09ED3ECC398F2000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [ipwave] Intdir telechat review of draft-ietf-ipwave-vehicular-networking-27
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Feb 2022 18:09:40 -0000

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?

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. 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?

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? 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? 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?

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?

Thanks in advance for your insights.

Fred Templin

> -----Original Message-----
> From: its [] On Behalf Of Pascal Thubert via Datatracker
> Sent: Monday, February 28, 2022 5:57 AM
> To:
> Cc:;;
> 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
> <>.
> 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