Subject: Re: [its] Charter comments

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 8 Aug 2016 13:47:18 -0500

Hi Russ,

Regarding  the charter, I have a comment:

I think that
Intelligent Transportation Systems (its),
is too generic for this group.

I see that the informational item called ITS General Problem Area is
something that is being taken up. The standards track work is very
specific work and calling it ITS is in my view not appropriate.

I suggest calling Vehicule to Internet Communications or vic would be
much more appropriate.
After all, IETF WGs with too generic names are not good, maybe OK for
IRTF like ICN.

Regards,

Behcet

On Thu, Jul 28, 2016 at 9:23 AM, Russ Housley <[email-masked]> wrote:
> I got word from our Area Director that the IESG would like to see a statement in the charter about coordination with IEEE 802.11.  I added it.
>
> Here is the diff: https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart?action=diff&version=19
>
> Here is the full charter: https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart
>
> Russ
>
>
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 9 Aug 2016 11:13:30 -0400

Considering what I see presented at ITS World Congress, I have to agree 
with Behcet on this one.

We are focused on Internet to (and perhaps into) the vehicle. Internet 
to transportation infrastructure is almost a given and perhaps not so 
interesting.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Aug 2016 12:01:36 +0200

Hi Behcet,

I tend to agree with the note, but here is some aspects in defence of 'ITS'.

'ITS' can be too generic, but compared to the other ITS there is a 
catch: it's at IETF :-)

For the V2I aspect: the initial work on problem statement 
(draft-petrescu-its-problem-03.txt, 
draft-jeong-its-v2i-problem-statement-02) describe use-cases exhbiting 
both Vehicle-to-Internet and Vehicle-to-Vehicle communication needs.  As 
such it would be little appropriate to call the group with an acronym 
based only on V2I.

The ongoing Stds Track work is IPv6-over-802.11-OCB which is applied 
equally well for vehicle-to-vehicle direct communications, and for 
vehicle-to-Internet (via an RSU).

If on the other hand one considers that two directly connected vehicles 
form already a small island of a small Internet, then a 3rd vehicle 
connecting to this island _could_ be called V2I.

Alex

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 15 Aug 2016 11:31:55 -0500

Hi Alex,

On Thu, Aug 11, 2016 at 5:01 AM, Alexandre Petrescu
<[email-masked]> wrote:
> Hi Behcet,
>
> I tend to agree with the note,

Thanks :-)

> but here is some aspects in defence of 'ITS'.
>
> 'ITS' can be too generic, but compared to the other ITS there is a catch:
> it's at IETF :-)

Don't understand this?

> draft-jeong-its-v2i-problem-statement-02) describe use-cases exhbiting both
> Vehicle-to-Internet and Vehicle-to-Vehicle communication needs.  As such it
> would be little appropriate to call the group with an acronym based only on
> V2I.
>

Only a little.

> The ongoing Stds Track work is IPv6-over-802.11-OCB which is applied equally
> well for vehicle-to-vehicle direct communications, and for

If standard track work applies to a larger area, it is good for the WG
doing the work.

> If on the other hand one considers that two directly connected vehicles form
> already a small island of a small Internet, then a 3rd vehicle connecting to
> this island _could_ be called V2I.
>
Yes but no infrastructural nodes are involved?

Regards,

behcet
>>> I got word from our Area Director that the IESG would like to see a
>>> statement in the charter about coordination with IEEE 802.11.  I added it.
>>>
>>> Here is the diff:
>>> https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart?action=diff&version=19
>>>
>>> Here is the full charter:
>>> https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart
>>>
>>> Russ
>>>
>>>
>>>

---

From: Tony Li <[email-masked]>
Date: Mon, 15 Aug 2016 09:57:42 -0700

> On Aug 15, 2016, at 9:31 AM, Behcet Sarikaya <[email-masked]> wrote:
> 

Hi there,

Sorry I’m late to the discussion, but I’m missing out on the architectural difference here.

What does it matter if a node is a vehicle or infra? What do you consider a vehicle that’s parked?

Seems to me that a node is a node is a node…  If they are in range of each other, then they chat.

Tony

---

From: Jérôme Härri <[email-masked]>
Date: Mon, 15 Aug 2016 19:22:32 +0200

Dear All,

>From a pure L2 link, we should not make a major difference if vehicles are communicating V2V or V2I (beside the enhanced range available by RSUs)..a node is a node indeed. But from an IPv6 architecture, this will make a difference, as the  RSU may be connected to the IPv6 backbone and as such have additional properties (prefix, gateway etc..).

It is yet also not as simple to say that when two vehicles are in range that the communicate...of course they will (at least try), but there will be different aspects to consider. For example, if the vehicle is 'involved in traffic' and/or his 'engine is on/key in the ignition', then it will need to transmit CAM/BSM. 
So, the IPv6 will need to 'co-exist' with non IP higher priority traffic (and operate in different channels for instance). But when the car is not involved in traffic, engine and key off, then IPv6 might use the full spectrum of the ITS-G5 radio (no 1609.4 channel switching for instance..)

My two cents,

Cheers,

Jérôme  

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Tony Li
Sent: Monday 15 August 2016 18:58
To: [email-masked]
Cc: Alexandre Petrescu; [email-masked]
Subject: Re: [its] Charter comments

>> If on the other hand one considers that two directly connected 
>> vehicles form already a small island of a small Internet, then a 3rd 
>> vehicle connecting to this island _could_ be called V2I.
>> 

Hi there,

Tony

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 15 Aug 2016 13:13:09 -0500

I don't think V2V should be an IETF issue.

Regarding V2I, if you don't like it, propose another name.

Behcet

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 15 Aug 2016 11:19:53 -0700

> I don't think V2V should be an IETF issue.

I think what you mean Behcet, as others have stated, that maybe Internet protocols are not suitable and add more risk to the V2V case.

Tony, I think what it comes down to is, if the link-layer protocols interoperate, what value is an IP layer. The application here is very specific (don’t hit the car in front of me, don’t hit objects near me, and make this decision very fast) and assigning an address, doing DAD, and other chit chat before moving the critical app data may exceed the time budget required.

Dino

---

From: [email-masked]
Date: Mon, 15 Aug 2016 11:57:50 -0700

Dino, my dear old friend,

> Tony, I think what it comes down to is, if the link-layer protocols interoperate, what value is an IP layer.

As always, no node, or even pair of nodes, is an island. Metcalfe’s law (sic) strongly suggests that providing a more general connectivity will prove to be more powerful.

> The application here is very specific (don’t hit the car in front of me, don’t hit objects near me, and make this decision very fast) and assigning an address, doing DAD, and other chit chat before moving the critical app data may exceed the time budget required.

While safety is of course the paramount concern, over time there are a myriad number of other applications that can and should be done in the vehicle. Some of those will want to interact with the broader Internet. If we do not extend the Internet infrastructure to the vehicle directly, it will end up happening indirectly, and in a much more awkward manner.

As to DAD, it’s not at all clear to me that there needs to be a lot of latency involved here. Obviously a link local address has a very high likelihood of being unique. A safety application can always worry about which system is claiming that there will be an impact after it tries to avert the impact. And before you start in on security, authentication should definitely not be bound to link layer or network layer addressing: as always, that needs crypto.

Now, if there are specific reasons why things can’t work with IP, I’m open to hearing about them. But so far, I haven’t seen a thing.

> I think what you mean Behcet, as others have stated, that maybe Internet protocols are not suitable and add more risk to the V2V case.

I would welcome specific examples.

Seems like old times,
Tony

---

From: "Marc Linsner (mlinsner)" <[email-masked]>
Date: Mon, 15 Aug 2016 19:53:48 +0000

Tony,

It’s not that things can’t work on IP, but, for example, for the specific safety messages there is no need.  Ch. 172 in the US is for low power safety messages destined for a 200m (+/-) radius from the vehicle.  Adding IP to those message provides no value to that application.

-Marc-

> On Aug 15, 2016, at 2:57 PM, [email-masked] wrote:
> 
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 15 Aug 2016 15:54:33 -0700

> Dino, my dear old friend,

Right on both counts.  ;-)

> As always, no node, or even pair of nodes, is an island. Metcalfe’s law (sic) strongly suggests that providing a more general connectivity will prove to be more powerful.

We will need IP for V2I for sure. So if we have it for that, it can be used for V2V. But I think we need to make IPv6 much more light wait. Like perhaps, allowing the MAC address of the node be part of the IPv6 address so address resolution and DAD can be avoided.

> While safety is of course the paramount concern, over time there are a myriad number of other applications that can and should be done in the vehicle. Some of those will want to interact with the b…

We will extend infrastructure to vehicles. It simply a question if vehicle to vehicle should be IP. I think it should and can be, but others are skeptical.

> As to DAD, it’s not at all clear to me that there needs to be a lot of latency involved here. Obviously a link local address has a very high likelihood of being unique. A safety application can alw…

Agree on everything you said. But crypto does come at a cost (cost in time) if key exchange happens. Others could comment but I heard the time budget is around 10ms.

> Now, if there are specific reasons why things can’t work with IP, I’m open to hearing about them. But so far, I haven’t seen a thing.

Others can chime in.

> I would welcome specific examples.

Definitely. Doesn’t anything really change?  ;-)

Dino

---

From: [email-masked]
Date: Mon, 15 Aug 2016 16:21:36 -0700

> On Aug 15, 2016, at 12:53 PM, Marc Linsner (mlinsner) <[email-masked]> wrote:
> 

Marc,

True enough. However, for many other applications it makes a great deal of sense and is effectively going to be mandatory. Given that we have to have that infrastructure and it’s pretty mature, why not use it?

Tony

---

From: [email-masked]
Date: Mon, 15 Aug 2016 16:36:35 -0700

Dino,

> We will need IP for V2I for sure. So if we have it for that, it can be used for V2V. But I think we need to make IPv6 much more light wait. Like perhaps, allowing the MAC address of the node be par…

IPv6 already allows for that.  See RFC 4291, section 2.5.6 for link local addresses, plus section 2.5.1 for Modified EUI-64 interface identifiers. 

> We will extend infrastructure to vehicles. It simply a question if vehicle to vehicle should be IP. I think it should and can be, but others are skeptical.

Let’s show ‘em why it’s good...

> Agree on everything you said. But crypto does come at a cost (cost in time) if key exchange happens. Others could comment but I heard the time budget is around 10ms.

No argument, but that’s really orthogonal. Regardless of what layering you select, if you need strong authentication, then it has to come via crypto of some flavor.  Suggest we separate the debates.

> Definitely. Doesn’t anything really change?  ;-)

Only our hair and wrinkles. ;-)

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 15 Aug 2016 16:49:34 -0700

> No argument, but that’s really orthogonal. Regardless of what layering you select, if you need strong authentication, then it has to come via crypto of some flavor.  Suggest we separate the debates.

True, the cost will be paid no matter where it is done.

Dino

---

From: Jérôme Härri <[email-masked]>
Date: Tue, 16 Aug 2016 10:29:35 +0200

Dear All,

Let's try not to restart the already past debate on IP or not IP. The charter specifically mentions that this WG will NOT address safety-critical applications, for which non-IP solutions already exist and so far are largely sufficient. 

So, now if you consider that the applications considered by this WG will be either 'complementary' to safety or not safety-related, there is no debate related to 'IP or not IP'...IPv6 is required. Period. 

The only point we need to keep in mind is that IPv6 will need to co-exist with non-IP mechanisms, and due to the safety-critical nature of their applications, IPv6 should not create any 'protocol' interference with non-IP solutions (e.g. overhead, occupying channel, security/privacy breach etc..). 

But again, we already had a long discussion on this in the past: neither IEEE 1609 nor ETSI ITS accept IP (and IPv6) on their safety-critical channel (ch. 178 in US, ch. 180 in EU), so IPv6-related applications/services/protocols developed in this WG will be sent on a different channel. 

Security is one of the IP-nonIP 'co-existence' challenge we need to handle. It is not about complexity or time, but to be synch to the security/privacy fully controlled by the non-IP stack. Said it simple: when the non-IP stack changes its pseudonym and the ID of all its layers, so MUST do the IPv6 stack...otherwise we breach the security/privacy provision created by the non-IP stack..We can thus use their strategy if it is present (use the non-IP certificate/pseudonyms if available) or provide an strictly cryptographic equivalent one with other strategies..

Best Regards,

Jérôme  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday 16 August 2016 01:37
To: Dino Farinacci
Cc: [email-masked]; Jérôme Härri; Alexandre Petrescu; [email-masked]
Subject: Re: [its] Charter comments

Dino,

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 17 Aug 2016 12:30:07 -0700

We can make v2v for non-safety use-cases work very simply with IPv6 defined as EIDs. Here is a possible scenario:

(1) Each device is assigned a static/non-changing IPv6 EID.
(2) The low-order 64-bits maps to its MAC address.
(3) This EID can also be used for v2i use-cases. See my presentation how to map this EID to a predictive-RLOC set so the mobility problem has near-0 packet loss.

The EID knows what destination it wants to talk to in the v2i case. But in the v2v case, there needs to be some discovery (what is the IP/MAC in front of me on the road, what IP/MACs are following me). I presume this is already solved with the IEEE 1609 protocols.

So what if the high-order 64-bits of the IPv6 EID is well-known and allocated for ITS, then we can reverse map real quickly. For instance:

(1) 1609 tells me that a BCM I just received is from MAC 0000-1111-2222 for a car behind me.
(2) That means if I can give a weather report to the car by sending an IPv6 packet to 2001:5:xxxx::0000.1111.2222 perhaps (I chose 2001:5::/16 because it has been allocated by IANA for experimental use for LISP EIDs).
(3) And if there is any infra communication and third-party referrals, the IPv6 EID is the same.

And note, if the car is multi-homed, you DON’T need to have multiple provider assigned addresses. Just one EID, global, static, non-changing, independent from anything else.

Level of indirection,
Dino

> On Aug 17, 2016, at 11:43 AM, Dick Roy <[email-masked]> wrote:
> 
> Please do not confuse V2V with application exchanges between vehicles (and
> other devices) for safety purposes.  V2V exchanges on Ch172/180 (sending of
> BSMs and CAMs, etc.) is one of many ITS safety related applications.  A V2V
> exchange can (and very likely will) involve IP networking at some point in
> the path between source and destination (e.g. sending a "black-ice warning"
> to vehicles "many miles back" is a simple use case).  That said, Dino's
> comment below is worth remembering.  There will be applications that do not
> require a complex network layer to successfully complete their mission.
> There may be good reasons to NOT use IP networking in such situations.
> 
> RR
> 
> From: Dino Farinacci [mailto:[email-masked]] 
> Sent: Monday, August 15, 2016 2:20 PM
> To: [email-masked]
> Cc: Alexandre Petrescu; Tony Li; Jérôme Härri; [email-masked]
> I think what you mean Behcet, as others have stated, that maybe Internet
> protocols are not suitable and add more risk to the V2V case.
> 
> Tony, I think what it comes down to is, if the link-layer protocols
> interoperate, what value is an IP layer. The application here is very
> specific (don’t hit the car in front of me, don’t hit objects near me, and
> make this decision very fast) and assigning an address, doing DAD, and other
> chit chat before moving the critical app data may exceed the time budget
> required.
> 
> Dino
> 
>>> From a pure L2 link, we should not make a major difference if vehicles
> are communicating V2V or V2I (beside the enhanced range available by
> RSUs)..a node is a node indeed. But from an IPv6 architecture, this will
> make a difference, as the  RSU may be connected to the IPv6 backbone and as
> such have additional properties (prefix, gateway etc..).
>>> 
>>> It is yet also not as simple to say that when two vehicles are in range
> that the communicate...of course they will (at least try), but there will be
> different aspects to consider. For example, if the vehicle is 'involved in
> traffic' and/or his 'engine is on/key in the ignition', then it will need to
> transmit CAM/BSM.
>>> So, the IPv6 will need to 'co-exist' with non IP higher priority traffic
> (and operate in different channels for instance). But when the car is not
> involved in traffic, engine and key off, then IPv6 might use the full
> spectrum of the ITS-G5 radio (no 1609.4 channel switching for instance..)
>>> 
>>> My two cents,
>>> 
>>> Cheers,
>>> 
>>> Jérôme
>>>

---

From: [email-masked]
Date: Wed, 17 Aug 2016 12:42:32 -0700

> [RR] If they all are on the same LAN, and thereby running the same layer 2 protocols, then bridging works very well.  That was the point made earlier I believe. 

Agreed, with well-demonstrated scalability limitations. The point is that the ability to interact with the broader Internet will be compelling.

> [RR] As mentioned several times previously, the minimum 40 octet IPv6 header is unnecessary overhead for BSMs and significantly adds to channel congestion (which is already known to be an issue).

And I’m happy to stipulate the BSM case.  What else?

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 17 Aug 2016 14:25:15 -0700

> Sent: Wednesday, August 17, 2016 3:30 PM
> To: [email-masked]
> Cc: [email-masked]; Alexandre Petrescu; Tony Li; Jérôme Härri; [email-masked]
> [RR] There is no “its MAC address”.  They tumble! Yes, sessions break when they do, so this needs to be taken into account …

I mean if I discovered a MAC because because it is broadcasting and I want to talk back to it, then knowing the MAC address to build frames is kinda critical to know.  ;-)

> [RR] Not even close.  The IEEE 1609 protocols simply say … “do IPv6 according to RFCXXXX and friends” (except for the WRA in the service announcement of course).  

Well the whole point of this group is to make the protocols at multiple layers work better together.

> [RR] Fine, however, unless the car is out of range, you could simply have used WSMP and the same MAC address (which only works if the car behind you has implemented the “weather report reception” application behind some well-known port). Since you just received a BSM from him and you are travelling the same direction, you’d probably get through.  Now let’s assume you use IPv6 and send it

We can use layer-3 and layer-2 link-local multicast for all apps too. As long as the app doesn’t care if others in range get the packets. But I’m probably going to hear from people on this list, that bandwidth is precious so don’t use it gratituiosuly.

> to the address you quote.  What MAC address will you use?  Probably the broadcast address, because that’s the only one other than the transmitter BA that makes sense.  What will any receiver of that packet do with it?  Probably pitch it because it does not have IPv6 forwarding implemented, and even if it did, its routing tables will not be properly populated to tell it what to do...no time for discovery! :^))

We are talking about the other applications that could run that Tony was referring to. The car behind me won’t pitch the packet if it wants to receive weather reports. It has an app running with an open listen() socket.

Dino

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 22 Aug 2016 15:49:49 +0200

> I don't think V2V should be an IETF issue.

I dont know what you mean more precisely by "V2V"?

Two vehicles exchanging IP datagrams - via more or less infrastructure -
is obviously an IETF issue.

Some deployed applications already do so (coyote and others).

> Regarding V2I, if you don't like it, propose another name.

I dont know what you mean more precisely by V2I either.

V2I like in Mobile IP would not need development in other than existing WGs.

V2I like in a Road-Side Unit broadcasting Points of Interest is not
V2Internet (Mobile IP), yet it may use same IP datagrams as in V2V.

For these reasons, I believe V2I, V2V and V2Internet are hard to
distinguish, and as such it's hard to propose another name.

Alex

>> From a pure L2 link, we should not make a major difference if
>> vehicles are communicating V2V or V2I (beside the enhanced range
>> available by RSUs)..a node is a node indeed. But from an IPv6
>> architecture, this will make a difference, as the  RSU may be
>> connected to the IPv6 backbone and as such have additional
>> properties (prefix, gateway etc..).
>>
>> It is yet also not as simple to say that when two vehicles are in
>> range that the communicate...of course they will (at least try),
>> but there will be different aspects to consider. For example, if
>> the vehicle is 'involved in traffic' and/or his 'engine is on/key
>> in the ignition', then it will need to transmit CAM/BSM. So, the
>> IPv6 will need to 'co-exist' with non IP higher priority traffic
>> (and operate in different channels for instance). But when the car
>> is not involved in traffic, engine and key off, then IPv6 might use
>> the full spectrum of the ITS-G5 radio (no 1609.4 channel switching
>> for instance..)
>>
>> My two cents,
>>
>> Cheers,
>>
>> Jérôme
>>
>> -----Original Message----- From: its [mailto:[email-masked]]
>> On Behalf Of Tony Li Sent: Monday 15 August 2016 18:58 To:
>> [email-masked] Cc: Alexandre Petrescu; [email-masked] Subject: Re:
>> [its] Charter comments
>>
>>
>>>> vehicles form already a small island of a small Internet, then
>>>> a 3rd vehicle connecting to this island _could_ be called V2I.
>>>>
>> _______________________________________________ its mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/its
>>
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 22 Aug 2016 06:51:43 -0700

> V2Internet (Mobile IP), yet it may use same IP datagrams as in V2V.

But I would argue an RSU would be a perfect place as a default router for hosts (vehicles) to point to.

Dino

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 22 Aug 2016 15:54:49 +0200

> But I would argue an RSU would be a perfect place as a default router for hosts (vehicles) to point to.

Certainly, as long as the RSU is connected to Internet and is ready to 
act as a default router.

Alex

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 22 Aug 2016 06:57:49 -0700

By definition a default router, traditionally has good connectivity to Internet infrastructure.

Dino

> On Aug 22, 2016, at 6:54 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> Certainly, as long as the RSU is connected to Internet and is ready to act as a default router.
> 
> Alex
> 
>> 
>> Dino
>> 
>>

---

From: Jérôme Härri <[email-masked]>
Date: Mon, 22 Aug 2016 16:38:54 +0200

Gentlemen,

When we use V2I or V2V (in the charter as well as in major publications), this is not to imply any technical detail, but rather to describe communication patterns: horizontal or vertical. The rest is just subject to interpretations, which sometimes are not accurate. Just as V2I does not strongly imply IPv6, V2V does not strongly reject IPv6...

A RSU is an ITS-S in the ETSI/ISO denomination. It may or may not be static, and may or may not be equipped with a IPv6 Mobile Router. That should be sufficient to differentiate the 'technical' differences of V2I...
 
In the charter, V2V and V2I are considered in a general (and simple) sense: horizontal (direct) vs, indirect (over an "infrastructure"....whatever it means)...I do not think we need to change that...but in one of our IDs, we could clarify this in technical terms. Such taxonomy could help, even beyond the IETF community I would guess...

Best Regards,

Jérôme

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Monday 22 August 2016 15:50
To: [email-masked]; Jérôme Härri
Cc: Tony Li; [email-masked]
Subject: Re: [its] Charter comments

Two vehicles exchanging IP datagrams - via more or less infrastructure - is obviously an IETF issue.

V2I like in a Road-Side Unit broadcasting Points of Interest is not V2Internet (Mobile IP), yet it may use same IP datagrams as in V2V.

For these reasons, I believe V2I, V2V and V2Internet are hard to distinguish, and as such it's hard to propose another name.

Alex

>> connected to the IPv6 backbone and as such have additional properties 
>> (prefix, gateway etc..).
>>
>> range that the communicate...of course they will (at least try), but 
>> there will be different aspects to consider. For example, if the 
>> vehicle is 'involved in traffic' and/or his 'engine is on/key in the 
>> ignition', then it will need to transmit CAM/BSM. So, the
>> IPv6 will need to 'co-exist' with non IP higher priority traffic (and 
>> operate in different channels for instance). But when the car is not 
>> -----Original Message----- From: its [mailto:[email-masked]] On 
>> Behalf Of Tony Li Sent: Monday 15 August 2016 18:58 To:
>>>> vehicles form already a small island of a small Internet, then a 
>>>> 3rd vehicle connecting to this island _could_ be called V2I.
>>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 22 Aug 2016 16:40:48 +0200

> to Internet infrastructure.

And that is a difference with many deployed RSUs.

Many deployed RSUs are disconnected from the Internet - there is simply
no Internet arriving to them.

Many RSUs which _are_ connected to the Internet have strong barriers
between the interface connected to the Internet and the interface to the
vehicles.  The interface to the Internet is very necessary for remote
management.  But the fear of risk of forwarding between the two
interfaces is very high.  Moreover, some applications are bound to
particular hardware, and so RSU is made of multiple boxes, which renders
forwarding further complex to a trivial plan.

Alex

>>>> V2I like in a Road-Side Unit broadcasting Points of Interest is
>>>> not V2Internet (Mobile IP), yet it may use same IP datagrams as
>>>> in V2V.
>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 22 Aug 2016 16:41:47 +0200

Le 22/08/2016 à 16:38, Jérôme Härri a écrit :
> Gentlemen,
>
> When we use V2I or V2V (in the charter as well as in major
> publications), this is not to imply any technical detail, but rather
> to describe communication patterns: horizontal or vertical. The rest
> is just subject to interpretations, which sometimes are not accurate.
> Just as V2I does not strongly imply IPv6, V2V does not strongly
> reject IPv6...
>
> A RSU is an ITS-S in the ETSI/ISO denomination. It may or may not be
> static, and may or may not be equipped with a IPv6 Mobile Router.
> That should be sufficient to differentiate the 'technical'
> differences of V2I...
>
> In the charter, V2V and V2I are considered in a general (and simple)
> sense: horizontal (direct) vs, indirect (over an
> "infrastructure"....whatever it means)...I do not think we need to
> change that...but in one of our IDs, we could clarify this in
> technical terms. Such taxonomy could help, even beyond the IETF
> community I would guess...

I agree.  It sounds like a good idea.

Alex

>
> Best Regards,
>
> Jérôme
>
> -----Original Message----- From: Alexandre Petrescu
> [mailto:[email-masked]] Sent: Monday 22 August 2016
> 15:50 To: [email-masked]; Jérôme Härri Cc: Tony Li; [email-masked]
> Two vehicles exchanging IP datagrams - via more or less
> infrastructure - is obviously an IETF issue.
>
>>> (and operate in different channels for instance). But when the
>>> car is not involved in traffic, engine and key off, then IPv6
>>> might use the full spectrum of the ITS-G5 radio (no 1609.4
>>> channel switching for instance..)
>>>
>>> My two cents,
>>>
>>> Cheers,
>>>
>>> Jérôme
>>>
>>> -----Original Message----- From: its
>>> [mailto:[email-masked]] On Behalf Of Tony Li Sent: Monday
>>> 15 August 2016 18:58 To: [email-masked] Cc: Alexandre
>>> Petrescu; [email-masked] Subject: Re: [its] Charter comments
>>>
>>>
>>>>> If on the other hand one considers that two directly
>>>>> connected vehicles form already a small island of a small
>>>>> Internet, then a 3rd vehicle connecting to this island
>>>>> _could_ be called V2I.
>>>>>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 22 Aug 2016 07:48:22 -0700

> forwarding further complex to a trivial plan.

The question is if this ship has already sailed. Today we have decent v2i by use of our cell phones. So the host (vehicle) is the router as well. 

Another question is if a RSU, one that is upgraded with a decent amount of bandwidth, can serve multiple host-only vehicles. Meaning, providing *better* mobility then the "large subnet everywhere" that cellular mobility provides today. 

Note the future is bound to have multiple wireless technologies. And not just LTE and 5G. So mobility across providers is a necessity. This is where a smarter, router-based, RSU will be needed. 

Dino

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 22 Aug 2016 14:00:39 -0500

> I dont know what you mean more precisely by "V2V"?

What is called horizontal communication.

> V2I like in Mobile IP would not need development in other than existing WGs.

Mobility is out of scope at least in the current charter, I think.

> distinguish, and as such it's hard to propose another name.

Disagree.
 I saw this in your draft:
Wireless Access in Vehicular Environments,
it could be used with a small change like

Wireless IP Access in Vehicular Environments

I think this name would reflect much better the charter.
Maybe in future versions you may use the great word of intelligent :-)

Regards,

Behcet

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 23 Aug 2016 11:19:20 +0200

Behcet,

I want to clarify that this message was addressed to you, and inform the
list as well.

I want to clarify that V2V, V2I are terms used differently in different
contexts.  The frequent misinterpretations make that it's difficult to
base a name of the group on one of these terms (I cant respond to your
invitation to propose another name based on these terms).

Also, if you look at the proposed work items:
> 1. Standards Track RFC "IPv6 over 802.11p"
>
> 2. Potential Informational RFC "ITS General Problem Area" covering: -
> What is ITS? -- Explain V2V, V2I, and related terms - Why is IPv6
> needed? -- Explain why some traffic will not use IPv6 -- Explain why
> other traffic will use IPv6 - Use-cases, illustrating the expected
> areas for initial focus - Informative references, relationship with
> other SDOs
>
> 3. Potential Informational RFC "Problem Statement" covering: -
> Problem statement - Security considerations - Privacy considerations

you will see that the name ITS can be right:

The item 'IPv6 over 802.11p' can be used as much in a V2V, V2I or
V2Internet settings; just like IPv6-over-Ethernet is used on
datacenters, or on home office, while that group is called '6man' and
not 'datacenter'.

The informational items describe 'ITS General Problem Area' and 'Problem
Statement' which apply in vehicle communications.  As such 'ITS' is
again a good name.

Besides, there are multiple relationships with non-IETF groups which
bear the 'ITS' name ('ITS' at US DOT, ETSI TC 'ITS', ISO TC204 'ITS' and
more).

For the word 'intelligent': I could agree that claiming intelligence may
seem too self-important, if not outright pompous.  But at the same time,
one could read this as a modern capability, which evolved from 'analog'
communications to 'digital' and now to 'intelligent'.

Alex

Le 22/08/2016 à 15:49, Alexandre Petrescu a écrit :
>>> It is yet also not as simple to say that when two vehicles are
>>> in range that the communicate...of course they will (at least
>>> try), but there will be different aspects to consider. For
>>> example, if the vehicle is 'involved in traffic' and/or his
>>> 'engine is on/key in the ignition', then it will need to transmit
>>> CAM/BSM. So, the IPv6 will need to 'co-exist' with non IP higher
>>> priority traffic (and operate in different channels for
>>> instance). But when the car is not involved in traffic, engine
>>> and key off, then IPv6 might use the full spectrum of the ITS-G5
>>> radio (no 1609.4 channel switching for instance..)
>>>
>>> My two cents,
>>>
>>> Cheers,
>>>
>>> Jérôme
>>>

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 23 Aug 2016 16:14:30 +0200

Hi Behcet

I don't agree with the change of the name to VIC, the work-purpose of
standerdizing is not only of communication but technologies and services. I
understand that for the short term you see the work as communication, but
that is just a start in a large journey of work. Other WGs are already
working on parts that we need to use in our WG. ITS is the correct name for
the work because many organisations are using the name and it is about
systems not communications.

IMHO, the name VIC cannot be used because it suggests working for proposes
of interfaces to Internet system, which should be the work of other SDOs,
or our work after making our proposal for Vehicle-system. We in IETF think
that the IP is the future technology for Vehicles, so let us not market
against our system (so ITS is the IP system for vehicles) until market
chooses between technologies.

AB

On Mon, Aug 8, 2016 at 8:47 PM, Behcet Sarikaya <[email-masked]>
wrote:

> > Here is the diff: https://trac.tools.ietf.org/
> wg/its/trac/wiki/WikiStart?action=diff&version=19
> >

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 23 Aug 2016 17:28:41 +0200

Le 22/08/2016 à 16:48, Dino Farinacci a écrit :
>> between the interface connected to the Internet and the interface
>> to the vehicles.  The interface to the Internet is very necessary
>> for remote management.  But the fear of risk of forwarding between
>> the two interfaces is very high.  Moreover, some applications are
>> bound to particular hardware, and so RSU is made of multiple boxes,
>> which renders forwarding further complex to a trivial plan.
>
> The question is if this ship has already sailed.

Not at all.

> Today we have decent v2i by use of our cell phones. So the host
> (vehicle) is the router as well.

Some automobiles use owner's cell phones; some other automobiles use 
built-in M2M modules to get on Internet.  The addressed market segment 
of the automobile dictates this differentiation (it's not simply a 
question of price).

New automobile makers regularly show up regularly, each trying a 
different formula to fill even more niches.  The connectivity aspects 
are each time very important criteria.

No, the ship has not already sailed.

> Another question is if a RSU, one that is upgraded with a decent
> amount of bandwidth, can serve multiple host-only vehicles. Meaning,
> providing *better* mobility then the "large subnet everywhere" that
> cellular mobility provides today.

I would guess yes, but we should not consider the vehicles to be 
host-only.  There are multiple IP-addressable devices within each 
vehicle (at least 32).

> Note the future is bound to have multiple wireless technologies. And
> not just LTE and 5G. So mobility across providers is a necessity.
> This is where a smarter, router-based, RSU will be needed.

I agree.

Alex

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 23 Aug 2016 10:29:50 -0500

Abdussalam, Alex,

You are referring to previous mails from me. The mail below is the
latest in which I proposed the name

wireless IP access in vehicular environments

not V*

or
IP access in vehicular environments

If this is (referring to my old mail) is deliberate, I protest it.

The other SDOs may use the word intelligent, it is their problem. I
think in IETF the name of the group should reflect the work to be
done.

Regards,

Behcet

---

From: Tony Li <[email-masked]>
Date: Tue, 23 Aug 2016 08:32:39 -0700

Folks,

If you’re not an IETF old-timer, you may not be aware that we have a tradition of trying to inject a little humor into our lives by creative naming of our WGs. ITS and VIC don’t begin to qualify in that regard. In that direction, I submit to you some alternative names:

	IPOD	- IP over DSRC
	ITSIT	- Intelligent Transportation Systems with IP Technology [c.f., It’s-it, a San Francisco ice cream treat]
	IVY		- IP for Vehicles Yesterday
	VIM		- Vehicles with Intelligent Management
	VICE	- Vehicles with IP Controller Enhancement
	VIP		- Vehicles with IP
	
I encourage further creativity.

Regards,
Tony

> On Aug 23, 2016, at 7:14 AM, Abdussalam Baryun <[email-masked]> wrote:
> 
> Hi Behcet
> 
> I don't agree with the change of the name to VIC, the work-purpose of standerdizing is not only of communication but technologies and services. I understand that for the short term you see the work as communication, but that is just a start in a large journey of work. Other WGs are already working on parts that we need to use in our WG. ITS is the correct name for the work because many organisations are using the name and it is about systems not communications.
> 
> IMHO, the name VIC cannot be used because it suggests working for proposes of interfaces to Internet system, which should be the work of other SDOs, or our work after making our proposal for Vehicle-system. We in IETF think that the IP is the future technology for Vehicles, so let us not market against our system (so ITS is the IP system for vehicles) until market chooses between technologies.
> 
> AB
> 
> On Mon, Aug 8, 2016 at 8:47 PM, Behcet Sarikaya <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Russ,
> 
> On Thu, Jul 28, 2016 at 9:23 AM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> > Here is the diff: https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart?action=diff&version=19 <https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart?action=diff&version=19>
> >
> > Here is the full charter: https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart <https://trac.tools.ietf.org/wg/its/trac/wiki/WikiStart>
> >
> > Russ
> >
> >
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>
>