Re: [ipwave] WG Last Call for draft-ietf-ipwave-vehicular-networking-16

"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Tue, 14 July 2020 02:25 UTC

Return-Path: <jaehoon.paul@gmail.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 EBAD93A0EB2 for <its@ietfa.amsl.com>; Mon, 13 Jul 2020 19:25:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HK_NAME_FM_MR_MRS=0.001, 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=gmail.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 0f0a-cHIdltM for <its@ietfa.amsl.com>; Mon, 13 Jul 2020 19:25:40 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900AB3A0EAF for <its@ietf.org>; Mon, 13 Jul 2020 19:25:39 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id d17so20570962ljl.3 for <its@ietf.org>; Mon, 13 Jul 2020 19:25:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lRuKtgDH3DC5KDUSqDjyy/a2AFdOOuRjMM1RaAAxNro=; b=SC4uHawjSJ7Hu89PuFMC3NrwdefUAZelgGYz6ObHXi1Wr4uKYxVGvARW4nvrw8ripj 6BuB9LuGhQJhrRUz9oQVrh/jxijFmgBAD9McAktjZeVmQWYbEEkSaE1DRBgX3Sq2GUqZ Wxqu2F1gmOKRYpaiCWZacK8FMepnGwyNrh4QK51vJdeGke7x1Rs/ZeGBajSBPuGzcSAr c8UPZgp8Z6a6p0hON2ROJusWdKRiMBVn4XyzpVgQMRu7mB8IJxNWMN6mYXMyjQSJM4at LoowHh3LGDMND7zHAa0UuuVbo7UF3oh7GSXCVWHNoHLXDdroHvYroeDWKlLJ6JwuQvMf qEyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lRuKtgDH3DC5KDUSqDjyy/a2AFdOOuRjMM1RaAAxNro=; b=P474INDhERMVJ3yLzVE98b9AoRl+ukeM20O9GuvnH2turyNDQL3vR8PgspDx2dcM/g JuT0HRTWiyZy1ZxMo5C6cuXCkQPe7QO/qXseNEbDm8T9L70V0fu+1ui5gwkOuzc/A3FZ tfNp/gkdQWqxcfGyKn3IXNmK2X7Ekzy08TT/NGwt9sMd/b2t80WMg6AcBVNlAvNZouFK zll8eLyXKV1q7tkOp2oXE3v15n9YSOKR1j7oiQ+tvHnhIwvEuPRyATE6Hq/FAaDtMmQ5 XpfFlWSPR71OPaRDr4KKtOtVMnWFExYP/jL7OLOj6iMyX1BUk/hxigWefBKQuN+vGbkq 7lUg==
X-Gm-Message-State: AOAM530JiCMpdF7ooZwLWbukqyidEVhMgkUhvj6TFiBkEoBlpGFgs61+ SwXhkHV4uooBMvq9dtysJai4rU9h0mT+1IUrLomCPA==
X-Google-Smtp-Source: ABdhPJy5xuhqO+fFrT2XeCDXjvvjM0RARVGn06G232U/DmYWais6BFAd/eLr76dfY8xOnU46kVmCJcKpte7AlP2UdQ8=
X-Received: by 2002:a05:651c:1116:: with SMTP id d22mr1221121ljo.170.1594693537763; Mon, 13 Jul 2020 19:25:37 -0700 (PDT)
MIME-Version: 1.0
References: <b17e4bc01d634196a47271c257c43e80@boeing.com>
In-Reply-To: <b17e4bc01d634196a47271c257c43e80@boeing.com>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Tue, 14 Jul 2020 11:25:02 +0900
Message-ID: <CAPK2DewQFUF8Dcu9rO=5QpEjsAtDFMzpDOMLXR_31ZGRAkP9GQ@mail.gmail.com>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
Cc: Russ Housley <housley@vigilsec.com>, its <its@ietf.org>, skku-iotlab-members <skku-iotlab-members@googlegroups.com>, "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d8151405aa5d85b4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/XDdNUKxVeoFejiAMeDjLl65Gwgo>
Subject: Re: [ipwave] WG Last Call for draft-ietf-ipwave-vehicular-networking-16
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: Tue, 14 Jul 2020 02:25:43 -0000

Hi Fred,
I think your suggested text looks good to me.
If there are no comments on your text, I will reflect them on the next
revision.

Thanks a lot.

Best Regards,
Paul

On Tue, Jul 14, 2020 at 2:25 AM Templin (US), Fred L <
Fred.L.Templin@boeing.com> wrote:

> Authors,
>
> First, a word of thanks for the changes you have made based on my comments
> to date.
> However, as I indicated in my 7/4/2020 message the changes did not
> comprehensively
> address all of my intended meaning. I have therefore re-reviewed the -16
> and include
> pointed comments below with explicit text change/addition suggestions.
>
> Please incorporate these changes in the next document version.
>
> Thanks - Fred
> fred.l.templin@boeing.com
>
> 1) Section 3.1, the bullet: "Collision avoidance service of end systems
>    of Urban Air Mobility (UAM).". Please cite [UAM-ITS] here on first
>    use of the term "UAM".
>
> 2) Section 3.1, the second-to-last paragraph beginning "The existing IPv6
>    protocol does not support wireless single-hop V2V communications as well
>    as wireless multihop V2V communications." Change to: "The existing IPv6
>    protocol must be augmented through the addition of an Overlay Multilink
>    Network (OMNI) Interface [OMNI] and/or protocol changes in order to
>    support wireless single-hop V2V communications as well as wireless
>    multihop V2V communications."
>
> 3) Section 3.2, the paragraph: "The existing IPv6 protocol does not support
>    wireless multihop V2I communications in a highway where RSUs are
> sparsely
>    deployed,". Change to: "The existing IPv6 protocol must be augmented
> through
>    the addition of an OMNI interface and/or protocol changes in order to
>    support wireless multihop V2I communications in a highway where RSUs are
>    sparsely deployed,".
>
> 4) Section 3.3, the paragraph: "The existing IPv6 protocol does not support
>    wireless mutihop V2X (or V2I2X) communications in an urban road network
>    where RSUs are deployed at intersections,". Change to: "The existing
> IPv6
>    protocol must be augmented through the addition of an OMNI interface
> and/or
>    protocol changes in order to support wireless multihop V2X (or V2I2X)
>    communications in an urban road network where RSUs are deployed
>    at intersections.,".
>
> 5) Section 4.1, the sentence: "For example, RPL (IPv6 Routing Protocol for
>    Low-Power and Lossy Networks) [RFC6550] can be extended to support a
>    multihop V2I since a vehicle". Change to: "For example, the OMNI
> interface
>    and/or RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks)
> [RFC6550]
>    can be extended to support a multihop V2I since a vehicle"
>
> 6) Section 4.1, the paragraph beginning: "Multiple vehicles under the
> coverage
>    of an RSU share a prefix such that mobile nodes share a prefix of a
> Wi-Fi
>    access point in a wireless LAN." Add the following as a final sentence
> to
>    this paragraph: "Alternatively, mobile nodes can employ an OMNI
> interface
>    and use their own IPv6 Unique Local Addresses (ULAs) [RFC4193] over the
>    wireless network without requiring stateless address
> autoconfiguration-related
>    messaging using an on-link prefix provided by the (visited) wireless
> LAN;
>    this technique is known as "Bring-Your-Own-Addresses".
>
> 7) Section 4.1, the paragraph beginning: "A single subnet prefix announced
> by
>    an RSU can span multiple vehicles in VANET." Add the following as a
> final
>    sentence to this paragraph: "Alternatively, each vehicle could employ an
>    OMNI interface with their own ULAs such that no topologically-oriented
>    subnet prefixes need be announced by the RSU."
>
> 8) Section 4.1, the paragraph beginning: "An IPv6 mobility solution is
> needed
>    for the guarantee of communication continuity". Add "AERO" as a second
>    example of a network-based mobility management scheme, i.e., change the
>    final sentence to "...or a network-based mobility management scheme
>    (e.g., PMIPv6 [RFC5213], AERO [RFC6706BIS], etc.)."
>
> 9)  Section 4.2, Figure 3 shows the address "2001:DB8:1:1::/64" on the
>    wireless interface of Vehicle1. Place parenthesis around this address
>    (i.e., as "(2001:DB8:1:1::/64)") to indicate that the address will
>    not be present when the OMNI interface is used (see next comment).
>
> 10) Section 4.2, the paragraph beginning: "As shown in Figure 3, global
>     IPv6 addresses are used for the wireless link interfaces for IP-OBU and
>     IP-RSU,". Change to: "As shown in Figure 3, the addresses used for
>     IPv6 transmissions over the wireless link interfaces for IP-OBU and
>     IP-RSU can be either global IPv6 addresses, or IPv6 ULAs as long as
>     IPv6 packets can be routed within vehicular networks [OMNI]. When
>     global IPv6 addresses are used, wireless interface configuration and
>     control overhead for DAD and MLD should be minimized to support V2I
>     and V2X communications for vehicles moving fast along roadways; when
>     ULAs and the OMNI interface are used, no DAD nor MLD messaging is
>     needed."
>
> 11) Section 4.3, Figure 4, same comment as 9) above - place parenthesis
>     around the address "(2001:DB8:1:1::/64)".
>
> 12) Section 4.3, the sentence: "Vehicle1's IP-OBU1 (as a mobile router)
>     and Vehicle2's IP-OBU2 (as a mobile router) use 2001:DB8:1:1::/64 for
>     an external link (e.g., DSRC) for V2V networking." Add a new sentence
>     immediately after this one as follows: "Alternatively, Vehicle1 and
>     Vehicle2 employ an OMNI interface and use IPv6 ULAs for V2V
> networking."
>
> 13) Section 5.1, first paragraph, the sentence: IPv6 ND is designed for
>     point-to-point links and transit links (e.g., Ethernet). Change to:
>     "IPv6 ND is designed for link types including point-to-point,
>     multicast-capable (e.g., Ethernet) and Non-Broadcast Multiple Access
> (NBMA)."
>
> 14) Section 5.1, first paragraph, final sentence ending: "such as MAC
>     Address Resolution (AR), Duplicate Address Detection (DAD) and
>     Neighbor Unreachability Detection (NUD)." Change to: "such as MAC
>     Address Resolution (AR), Duplicate Address Detection (DAD), Multicast
>     Listener Discovery (MLD) and Neighbor Unreachability Detection (NUD)."
>
> 15) Section 5.1.1 (Link Model), the sentence: "Note that the OMNI link
> model
>     supports these multihop V2V and V2I through an OMNI multilink service
>     [OMNI-Interface].", change to: "Note that the OMNI interface supports
>     an NBMA link model where multihop V2V and V2I communications use each
>     mobile node's ULAs without need for any DAD or MLD messaging."
>
> 16) Section 5.1.1, the sentence: "IPv6 protocols work under certain
> assumptions
>     for the link model that do not necessarily hold in a vehicular wireless
>     link [VIP-WAVE][RFC5889]". Change to: "IPv6 protocols work under
> certain
>     assumptions that do not necessarily hold for vehicular wireless access
>     link types other than OMNI/NBMA [VIP-WAVE][RFC5889]; the rest of this
>     section discusses implications for those link types that do not apply
>     when the OMNI/NBMA link model is used.".
>
> 17) Section 5.1.1, final paragraph, change to: "Thus, in IPv6-based
> vehicular
>     networking, the vehicular link model should have minimum changes for
>     interoperability with standard IPv6 links in an efficient fashion to
> support
>     IPv6 DAD, MLD and NUD operations. When the OMNI NBMA link model is
> used,
>     there are no link model changes nor DAD/MLD messaging required."
>
> 18) Section 5.1.3, the sentence: "For multihop V2V communications in either
>     a VANET or VANETs via IP-RSUs, a vehicular ad hoc routing protocol
> (e.g.,
>     AODV or OLSRv2) may be required". Please either enumerate all protocol
>     types (e.g., AODV, DSR, OLSRv2, OSPF-MANET, TBRPF, etc.) or simply
> refer
>     to them collectively as "MANET protocols". Suggestion is the later, and
>     proposed rewrite is: "For multihop V2V communications in either a VANET
>     or VANETs via IP-RSUs, a vehicular Mobile Ad-hoc Networking (MANET)
>     routing protocol may be required".
>
> 19) Throughout the document, please change the citation for OMNI from
>     "[OMNI-Interface]" to simply "[OMNI]".
>
> > This is the IPWAVE WG Last Call for "IPv6 Wireless Access in Vehicular
> Environments (IPWAVE): Problem Statement and Use Cases”
> > <draft-ietf-ipwave-vehicular-networking-16>.  Please review the document
> and send your comments to the list by 26 July 2020.
> >
> > The datatracker page for the document is
> https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/
> >
> > Thanks,
> > Russ & Carlos
> >
> > _______________________________________________
> > its mailing list
> > its@ietf.org
> > https://www.ietf.org/mailman/listinfo/its
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its
>


-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Computer Science and Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com, pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>