Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-26.txt
"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Fri, 25 February 2022 18:38 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 3531C3A0D2D for <its@ietfa.amsl.com>; Fri, 25 Feb 2022 10:38:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 lb3VTnkHGW1q for <its@ietfa.amsl.com>; Fri, 25 Feb 2022 10:38:40 -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 4D9B43A0105 for <its@ietf.org>; Fri, 25 Feb 2022 10:38:39 -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 21PIcZcc007882; Fri, 25 Feb 2022 13:38:37 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1645814317; bh=zkq1ie+Qm8pipL2QyHapoz3Z6ubgHAPpvEvwOlR1CFc=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ocmM7rpjpohi1DGeGeeiKTxxTwkFFiVcQNAsehwQYLC+xL/X5lAlEvrHiDwuKoRKs CZHQULIBCxhQaTfTqlJo63jlTuhjlA7PpnjWfR5o+cb35KoatDZnOVDZ9qjXOFeGz1 RK9fVeOAk6SB3mexcLpIeTnOukmS7gMt4DembGs2fewR/e95VkAzMqR1xqcuoCWFiZ Cnz6p2yw3eBLu6+RHSbpfXYWzxG0VDX1krO2DrJQg0xFBCnCyVEdW01qY93p77pi5P dSjphoJG2crULc4Aou/9ztYEa4e8/V+scfaeOVOwznIlyO11XCs77bhtHwsVNVOqEI tYd8HxskjtkvQ==
Received: from XCH16-07-12.nos.boeing.com (xch16-07-12.nos.boeing.com [144.115.66.114]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 21PIcRdW007764 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 25 Feb 2022 13:38:27 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-12.nos.boeing.com (144.115.66.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.18; Fri, 25 Feb 2022 10:38:26 -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; Fri, 25 Feb 2022 10:38:26 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Erik Kline <ek.ietf@gmail.com>
CC: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "housley@vigilsec.com" <housley@vigilsec.com>, "jaehoon.paul@gmail.com" <jaehoon.paul@gmail.com>, "its@ietf.org" <its@ietf.org>, "Dirk.von-Hugo@telekom.de" <Dirk.von-Hugo@telekom.de>
Thread-Topic: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-26.txt
Thread-Index: Adgqc/ODHqNCprdfR0uKSeBlBnBn7gAAoumg
Date: Fri, 25 Feb 2022 18:38:26 +0000
Message-ID: <70c78dd1bac14635aefdb185b9b23ab0@boeing.com>
References: <5cd3048f7d5946bcb2aefebae3138fb7@boeing.com>
In-Reply-To: <5cd3048f7d5946bcb2aefebae3138fb7@boeing.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: CE78AFE3F14FB7316CA0FE26BD40FD00A2012B74B5273AD0C6CB929289FE47D52000:8
Content-Type: multipart/alternative; boundary="_000_70c78dd1bac14635aefdb185b9b23ab0boeingcom_"
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/_rxE4_aq9sColiIrU46O2Hf9mug>
Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-26.txt
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: Fri, 25 Feb 2022 18:38:46 -0000
Eric, since there seems to be some interest here I would direct the group to my recent article posted to the APNIC Blog: https://blog.apnic.net/2022/02/18/omni-an-adaptation-layer-for-the-internet/ This is the first article in a series that will be unfolding in the coming months; it might be a good series to go into more details on the “6M’s”. Thanks - Fred From: its [mailto:its-bounces@ietf.org] On Behalf Of Templin (US), Fred L Sent: Friday, February 25, 2022 10:21 AM To: Erik Kline <ek.ietf@gmail.com> Cc: Pascal Thubert (pthubert) <pthubert@cisco.com>; housley@vigilsec.com; jaehoon.paul@gmail.com; its@ietf.org; Dirk.von-Hugo@telekom.de Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-26.txt Erik, the only place I know of that you will find the “6M’s” discussed are in AERO/OMNI themselves. Those documents are currently in the RFC ISE queue, but could probably serve the community better if they were brought into an IETF working group and/or advanced through some other standards-track publication approach. Any thoughts? Thanks - Fred From: Erik Kline [mailto:ek.ietf@gmail.com] Sent: Thursday, February 24, 2022 3:59 PM To: Templin (US), Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> Cc: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>; housley@vigilsec.com<mailto:housley@vigilsec.com>; jaehoon.paul@gmail.com<mailto:jaehoon.paul@gmail.com>; its@ietf.org<mailto:its@ietf.org>; Dirk.von-Hugo@telekom.de<mailto:Dirk.von-Hugo@telekom.de> Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-26.txt Fred, I cannot find (via some light Google searching) any reference to an industry standard understanding of these "6 Ms". If we're going to set down Principles of Networking like this I wonder if we should try to get more review or maybe look for some academic citation even. If there is existing literature on this I'd be interested to read it. Thanks, -Erik On Thu, Feb 24, 2022 at 12:51 PM Templin (US), Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote: All, see below for my comments on 'draft-ietf-ipwave-vehicular-networking-26.txt'. It might be worth noting that my colleagues and I have been looking at vehicular communications use cases for a long time (e.g., see: RANGERS [RFC6139]). Indeed, support for vehicular communications of all forms (land, sea, air, space) has long been the driving force behind the AERO and OMNI technologies which have taken their current shape as a result. Please see below for comments and make corresponding changes to the document. Fred Templin --- Comments on 'draft-ietf-ipwave-vehicular-networking-26.txt': ************************************************** 1) Section 1, change: "Asymmetric Extended Route Optimization (AERO) [I-D.templin-6man-aero]" to: "Automatic Extended Route Optimization based on the Overlay Multilink Network Interface (AERO/OMNI) [I-D.templin-6man-aero][I-D.templin-6man-omni]". 2) Section 3, change: "The use cases presented in this section serve as the description and motivation for the need to extend IPv6 and its protocols to facilitate "Vehicular IPv6"." to: "The use cases presented in this section serve as the description and motivation for the need to augment IPv6 and its protocols to facilitate "Vehicular IPv6"." 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." 4) Section 3.3, change the paragraph beginning: "The existing IPv6 protocol must be augmented through protocol changes..." to: "The existing IPv6 protocol must be augmented through protocol changes or by including a new adaptation layer in the architecture that efficiently maps IPv6 to a diversity of underlying link layer technologies. Augmentation is necessary to support wireless multihop V2X or V2I2X communications in an urban road network where RSUs are deployed at intersections, so a vehicle (or a pedestrian's smartphone) can reach the wireless coverage of an RSU through the multihop data forwarding of intermediate vehicles (or pedestrians' smartphones) as packet forwarders." 5) Section 4.1, second paragraph, change: "OMNI (Overlay Multilink Network Interface) [I-D.templin-6man-omni]" to: "AERO/OMNI [I-D.templin-6man-aero][I-D.templin-6man-omni]". 6) Section 4.1, third paragraph, change: "Furthermore, the wireless media interfaces are autoconfigured with a global IPv6 prefix (e.g., 2001:DB8:1:1::/64) to support both V2V and V2I networking. Note that 2001:DB8::/32 is a documentation prefix [RFC3849] for example prefixes in this document, and also that any routable IPv6 address needs to be routable in a VANET and a vehicular network including IP-RSUs." to: "In a first addressing alternative, the wireless media interfaces are autoconfigured with a global IPv6 prefix (e.g., 2001:DB8:1:1::/64) to support both V2V and V2I networking. Note that 2001:DB8::/32 is a documentation prefix [RFC3849] for example prefixes in this document, and also that any routable IPv6 address needs to be routable in a VANET and a vehicular network including IP-RSUs. In a second alternative, each wireless media interface is configured with an IPv6 Unique Local Address (ULA) [RFC4193] that is assured unique within the vehicular network according to AERO/OMNI and [RFC5889]. The ULA supports both V2V and V2I multihop forwarding within the vehicular network (e.g., via a VANET routing protocol) while each vehicle can communicate with Internet correspondents using global IPv6 addresses via OMNI interface encapsulation over the wireless interface." 7) Section 4.1, fifth paragraph, change: "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]." to: "Alternatively, mobile nodes can configure IPv6 Unique Local Addresses (ULAs) according AERO/OMNI then support global communications through OMNI interface encapsulation and forwarding of packets with MNP-based global IPv6 addresses over the wireless networks. The use of AERO/OMNI ULA autoconfiguration assures uniqueness such that Duplicate Address Detection (DAD) of IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862] is not needed." 8) Section 4.2, add the following as a final paragraph: "In a second alternative when vehicles configure an OMNI interface over an underlying VANET based on ULA addressing, the global IPv6 addresses covered by the MNP on-board the vehicle are not injected into the VANET routing system but instead traverse the VANET in the forwarding plane via OMNI encapsulation. This allows each vehicle to maintain a constant and unchanging MNP delegation even as it moves between IP-RSUs. This avoids any need for vehicle on-board network renumbering due to mobility and avoids repeated injections and withdrawals of MNP prefixes within the VANET." 9) Section 4.3, add new paragraph following paragraph beginning "Figure 3 shows the internetworking" as follows: "When two vehicles within a ULA-based VANET need to communicate without the assistance of any infrastructure, they can exchange unencapsulated IPv6 packets with ULA-based addresses which will be forwarded according to the VANET routing protocol. Alternatively, the vehicles can use OMNI interface encapsulation to exchange IPv6 packets with global addresses taken from their respective MNPs. The encapsulation source and destination ULAs are algorithmically bound to the IPv6 source and destination global addresses which allows for stateless encapsulation address determination." 10) 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." 11) Section 5.1, second paragraph, 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" 12) Section 5.2, third paragraph, change: "An efficient DAD is required to reduce the overhead of the DAD packets during a vehicle's travel in a road network" to: "DAD is not needed in networks that follow the OMNI ULA autoconfiguration procedures. In other cases when DAD is needed, it must be made efficient to reduce the overhead of the DAD packets during a vehicle's travel in a road network" 13) Section 5.1.1, third paragraph, change: "There is a relationship between a link and a prefix, besides the different scopes that are expected from the link-local and global types of IPv6 addresses." to: "There is a relationship between a link and a prefix, besides the different scopes that are expected from the link-local, unique-local and global types of IPv6 addresses." 14) Section 5.1.1, add a new second-to-last paragraph as follows: "Often when two VANETs merge some vehicles may configure addresses from a first subnet prefix while other vehicles configure addresses from other subnet prefixes. These merge events must not interfere with the vehicle-to-vehicle multihop forwarding necessary to support continuous communications. Additionally, when a vehicle enters the network for the first time it may need to use a temporary ULA address in initial messages to negotiate with an IP-RSU for an address within the subnet. The VANET must therefore provide (short-term) forwarding for vehicles with foreign addresses, while the subnet prefix serves as an aggregation point of reference for a particular IP-RSU without impeding multihop forwarding between vehicles that may belong to different subnets." 15) Section 5.1.3 goes too far in expanding on RPL. It is based on the claim that: "However, it will be costly to run both vehicular ND and a vehicular ad hoc routing protocol in terms of control traffic overhead [RFC9119].". But, the AERO/OMNI approach uses only the MANET routing protocol control messages at the subnet level then applies unicast-only IPv6 ND messaging at the OMNI interface level so that there is no traffic amplification due to multicast IPv6 ND within the subnet. Therefore, a new third paragraph telling how it works in AERO/OMNI should be added as follows: "The AERO/OMNI approach avoids this issue by using MANET routing protocols only (i.e., and no multicast IPv6 ND messaging) in the wireless network underlay while applying efficient unicast IPv6 ND messaging in the OMNI overlay on an as-needed basis for router discovery and NUD. This greatly reduces the overhead for VANET-wide multicasting while providing agile accommodation for dynamic topology changes." Additionally, the RPL text should be reduced by at least 50%. 16) Section 5.2, paragraph 6 change: "Even though the SLAAC with classic ND costs a DAD during mobility management, the SLAAC with [RFC8505] does not cost a DAD." to: "Even though classic IPv6 ND requires the use of DAD on many link types during mobility management, address autoconfiguration based on [RFC8505] and/or AERO/OMNI does not require DAD." 17) Section 5.2, paragraph 6, remove the following text entirely: "On the other hand, a BYOA does not allow such direct routability to the Internet since the BYOA is not topologically correct, that is, not routable in the Internet. In addition, a vehicle configured with a BYOA needs a tunnel home (e.g., IP-RSU) connected to the Internet, and the vehicle needs to know which neighboring vehicle is reachable inside the VANET toward the tunnel home. There is nonnegligible control overhead to set up and maintain routes to such a tunnel home over the VANET." Reason: There is always a cost for maintaining mobility management for addresses within an MNP. It can be done either by frequent advertisements/withdrawals of the MNP in the global routing system or through coordination with a mobility anchor point in an overlay via encapsulation. The Connexion by Boeing experience showed that dynamic routing protocol updates do not scale in the global Internet. The AERO/OMNI services instead minimize routing protocol disturbance while using efficient mobility signaling in the overlay. 18) Section 5.2, near the end, remove the following sentence: "IP tunneling over the wireless link should be avoided for performance efficiency." Reason: IP tunneling is used only in support of global-scoped IPv6 communication (not local-scoped) and can use effective header compression for greater efficiency as in AERO/OMNI. In addition, there is value in using encapsulation both from the standpoint of minimizing global routing protocol overhead and by accommodating path MTU diversity (see below). 19) Add a new Section 5.3 as follows: "5.3 Accommodating MTU Diversity The wireless and/or wired-line links in paths between both mobile nodes and fixed network correspondents may configure a variety of Maximum Transmission Units (MTUs), where all IPv6 links are required to support a minimum MTU of 1280 octets and MAY support larger MTUs. Unfortunately, determining the path MTU (i.e., the minimum link MTU in the path) has proven to be inefficient and unreliable due to the uncertain nature of the loss-oriented ICMPv6 messaging service used for path MTU discovery. Recent developments have produced a more reliable path MTU determination service for TCP [RFC4821] and UDP [RFC8899] however the MTUs discovered are always limited by the most restrictive link MTU in the path (often 1500 octets or smaller). The AERO/OMNI service addresses the MTU issue by introducing a new layer in the Internet architecture known as the "OMNI Adaptation Layer (OAL)". The OAL allows end systems that configure an OMNI interface to utilize a full 65535 octet MTU by leveraging the IPv6 fragmentation and reassembly service during encapsulation to produce fragment sizes that are assured of traversing the path without loss due to a size restriction. (This allows end systems to send packets that are often much larger than the actual path MTU.) Performance studies over the course of many decades have proven that applications will see greater performance by sending smaller numbers of large packets (as opposed to larger numbers of small packets) even if fragmentation is needed. The OAL further supports even larger packet sizes through the IP Parcels construct [I-D.templin-intarea-parcels] which provides "packet-in-packet" encapsulation for a total size up to 4MB. Together, the OAL and IP Parcels will provide a revolutionary new capability for greater efficiency in both mobile and fixed networks." 20) Appendix B, add the following as a final paragraph: "AERO and OMNI together securely and efficiently address the following 6 M's of Modern Internetworking for mobile V2V, V2I and V2X Clients: 1. Multilink: A Client's ability to coordinate multiple diverse underlying data links as a single logical unit (i.e., the OMNI interface) to achieve the required communications performance and reliability objectives. 2. Multinet: The ability to span the OMNI link over a segment routing topology with multiple diverse administrative domain network segments while maintaining seamless E2E communications between mobile Clients and correspondents such as air traffic controllers and fleet administrators. 3. Mobility: A Client's ability to change network points of attachment (e.g., moving between wireless base stations) which may result in an underlying interface address change without disruptions to ongoing communication sessions with peers over the OMNI link. 4. Multicast: The ability to send a single network transmission that reaches multiple Clients belonging to the same interest group without disturbing other Clients not subscribed to the interest group. 5. Multihop: A mobile Client's V2V relaying capability useful when multiple forwarding hops between vehicles may be necessary to reach back to an infrastructure access point connection to the OMNI link. 6. MTU Assurance: The ability to deliver packets of various robust sizes between peers without loss due to a link size restriction, and to dynamically adjust packet sizes in order to achieve the optimal performance for each independent traffic flow."
- [ipwave] I-D Action: draft-ietf-ipwave-vehicular-… internet-drafts
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Templin (US), Fred L
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Templin (US), Fred L
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Russ Housley
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Templin (US), Fred L
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Mr. Jaehoon Paul Jeong
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Mr. Jaehoon Paul Jeong
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Templin (US), Fred L
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Dirk.von-Hugo
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Templin (US), Fred L
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Mr. Jaehoon Paul Jeong
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Erik Kline
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Erik Kline
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Dirk.von-Hugo
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Templin (US), Fred L
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Templin (US), Fred L
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Mr. Jaehoon Paul Jeong
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Erik Kline
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Templin (US), Fred L
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Templin (US), Fred L
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Templin (US), Fred L
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Rex Buddenberg
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Templin (US), Fred L
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Templin (US), Fred L
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Mr. Jaehoon Paul Jeong
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Templin (US), Fred L
- Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicu… Mr. Jaehoon Paul Jeong
- Re: [ipwave] [EXTERNAL] Re: I-D Action: draft-iet… Templin (US), Fred L