Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-14.txt

["Z.W. Yan" <[e-mail]>]

Hi, All,
I reviewed this IPWAVE PS draft and have the following comments for your reference:
1) In Section 1, the ITS/WAVE based standards are introduced, but the IPv6/MIPv6/PMIPv6 are not so proper here because 
these protocols (as other TCP/IP protocols) are not dedicated to ITS. Then it will be better if there is some 
works/extensions to be added particular for ITS based on IPv6.
2) In page 4, “Edge Network (EN): In is an access network” should be “Edge Network (EN): It is an access network”.
3) In page 4, why EC and ECD are for the sake of vehicles and pedestrians, while EN is only for the sake of vehicles?
4) In page 4-5, the ITS related functions (such as measuring, sensing or communicating) can be executed by any device with 
the related ability. Then the draft should use “vehicle” (defined in Page5) as a representative “device” but not just 
denote “car” although typically it is “car”. It’s better to explains this more clearly and put this definition in front.
5) In Section 3, it will be clearer if the organization can be adjusted as: V2V/V2I/V2X definitions, use cases explanations 
of V2V/V2I/V2X and challenge analysis of these use cases under IPv6.
6) In Subsection 4.1, more explanation is needed “However, some components in the vehicular network architecture may not 
be needed for vehicular networks, such as Vehicular Cloud, Traffic Control Center, and Mobility Anchor.” For example, 
because the related services are not deployed or requested. 
7) In Subsection 4.1, the PMIPv6 is mentioned but it is very unexpected and sudden. It’s better if the elements in Figure 
1 can be explained first, and then the related communications can be explained and at last the adopted and extended 
protocols involved (such as OCB and PMIP) can be explained.
8) In Subsection 4.1, in page 12, the mobility management is mentioned, but it’s better to describe mobility management as 
a protocol to guarantee the communication continuity. Because the mobility management protocols are not just used to 
maintain the TCP connectivity, but also to avoid the UDP packet loss or avoid the session disruption during network layer handover.
9) In Subsection 4.1, in page 12, both the host-based mobility management protocol and network-based mobility management 
protocol are introduced, but only PMIP as network-based mobility management protocol is mentioned before this part. And 
“an IP-RSU plays a role of a home agent in a visited network.” It should be checked, whether MA acts as HA or IP-RSU acts as HA.
10) Why SDN can only be adopted in mobility management process?
11) In Subsection 5.1, the ND protocol challenges are analyzed. This should be analyzed corresponding to the mobility 
management protocols deployed. If MIPv6 is used or without mobility management support, the vehicle needs to configure an 
IPv6 address in the shared link and then the DAD is needed. However, if PMIPv6 is used, the vehicle can receive a unique 
IPv6 prefix through the point-to-point link with RUS and then the DAD is unnecessary. And due to the applications in ITS 
always need the configuration to be finished as fast as possible, then the traditional DAD should not be used directly 
because its inefficiency.
12) In Subsection 5.2, the mobility management should be performed more efficiently with the help of GPS and ND protocol 
(at least). Also here, the above problem exists because the vehicle may use PMIP or MIP. Besides, the vehicle may also use 
DHCP for address/prefix configuration but not only SLAAC.
BR,
Zhiwei Yan