Subject: [its] New IETF Networking For ITS

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 17 Feb 2013 12:34:53 +0100

Hi Folks,

For smart cities and their transportation (including communities), I
support the advise below of considering ETSI IPv6 over GeoNetworking
standard, however we may consider to add to it the OLSRv2 standard as
well because used in community networks. The geo-aware can be included
in OLSRv2. However, IMO a hybrid routing is a good alternative choice
for ITS, but also may consider I2R architecture [1] as a part in ITS
framework. The hybrid route design approach maybe similar to a
suggested one [2].

 I recommend this to be into framework-draft or discussed, but not
into the proposed charter because it will take time untill we agree on
the final approach of ITS networking,

[1] http://www.ietf.org/mail-archive/web/i2rs/current/msg00523.html
[2] http://www.ietf.org/mail-archive/web/manet/current/msg14738.html

AB

Sub: Re: [its] IPv6 and geonetworking (was: IP over 802.11p)
On 2/15/13, Alexandru Petrescu <[email-masked]> wrote:
> Le 15/02/2013 11:05, Roberto Baldessari a écrit :
>> Hi Alex,
>>
>>> I read the comment.  We could discuss it separately, in a separate
>>>  thread. Basically, I think inserting geography in such internal
>>> workings which is IP addressing changes the nature of this latter,
>>>  and may loose its widespread interoperability.  And yes, I should
>>>  look first at its advantages.  LEt's discuss separately.
>>
>> I think this is the right thread to discuss this point. But you can
>> rename the subject if you prefer.
>>
>> With IPv6 over GeoNetworking we do not modify IPv6, we only transport
>> it. So we are perfectly in line with what you said (maximize
>> interoperability). That's why we map IPv6 multicast into lower layer
>> (GeoNetworking) geocast and we do not make IPv6 geo-aware.
>
> I think it is good to prefer to make other layers geo-aware, instead of
> IP, because IP has its own notion of what is 'geography' - distance,
> metrics, topology - all mean different things in the IP architecture
> than to geography.
>
> In some aspects, geonetworking is not only multicast.  There may
> be more about geonetworking I still need to re-discover, but here is one
> particular aspect:
>
> 'C2C NET ID' which is used to form IPv6 addresses for vehicles.  I.e.
> such an address is formed based on the geographic position.  If so I
> think it is not good, because it means when no position no IP address.
>
> We propose to form IPv6 addresses for vehicles based on the VIN (Vehicle
> Identification Numbers), instead of the position.  The VIN is always
> there so addresses are always there.
>
> This is one aspect of IP addressing and geonetworking which deserves
> discussion.
>
>> Actually, at the very beginning of this group's discussion, I asked
>> if the group could review the ETSI IPv6 over GeoNetworking standard.
>
> YEs, I remember, you did.
>
>> It would have been useful to receive some IETF input.
>
> YEs, it would have been useful.  If you could send publicly once again
> the ref to that ETSI ITS document, on this list, I could send some
> feedback on some very minor aspects.  Please do send the ref.
>
> I want to add - the IETF input, in order to be qualified as such, should
> happen publicly, in an organized manner - working group, public
> discussion, public decisions.
>
> As a counter-example: my oppinion sent to you in private (even though I
> often participate at IETF) should not be qualified as an "IETF input".
>
> It's not that the IETF 'usual suspects' participate at another SDO that
> that input is IETF input.  We need documents, WG items, Charters for
> that to happen.
>
>> We have now submitted an update within ETSI ITS. If approved, it will
>> be published soon (< 1 month).
>
> Well this is good to submit to ETSI ITS.
>
>> Note that people who also participate(d) in IETF contributed to the
>> ETSI standard. So, I would not talk about IETF/ETSI as two separate
>> worlds. Rather, what is missing is some official/structured
>> cooperation to build on each other's expertise/standards.
>
> Yes, we need to have a structured input from IETF.
>
> We need to avoid a situation where IETF person X pretends Y to SDO,
> without giving a chance to another IETF person U to express counter-Y.
>
> Alex
>