[MEXT] Comments on draft-ietf-mext-nemo-ro-automotive-req-01.txt

Hello MEXTers,

I would like to offer comments on
draft-ietf-mext-nemo-ro-automotive-req-01.txt.  I find it very readable
and concise, well-formed.  I think we need this document.

I have some hopefully improving comments.

I think it would make sense to try to talk somewhere in the document
about IP-over-foo-technology.  It may give a good accompanying
perspective to the architecture-uses-IPv6 perspective currently
described.  It's very relevant to talk about IPv6-over-802.11p in a
document mentioning 802.11p and IPv6 several times.

Nit: page 5, 'composed of' is better than 'composed by'.

Still in the Terminology section, right after V2I definition, it would
be good to add V2I2V definition (vehicle to infra to vehicle), term used 
later in the document; I think the scenario is very relevant.

Figure 1: 'Mod IEEE 802.11p Interface'?  What does Mod mean?  I could
read it easily if it said 'Modified' or its abbreviation "Mod'ed".  But
'Mod' sounds too abbreviated :-)

Page 11:
> o  according to the current availability of infrastructure 
> connectivity, OBUs can use (at least) 2 types of globally routable 
> IPv6 addresses: an IPv6 address configured using standard IPv6 
> stateless address configuration from Router Advertisements sent by 
> RSUs connected to a network infrastructure and an IPv6 address 
> configured from a prefix permanently allocated to the vehicle and 
> delegated to the vehicle from a home network.  The former globally 
> routable IPv6 address is used as the NEMO Care-of Address (CoA) and 
> the latter as the NEMO Home Address (HoA).

For the second case, MR's Home Address derived from MNP.  One would make
sure to clarify that this behaviour is not standard NEMOv6, needs tweaks
on the MR and on the HA, as mentioned in section 5.3 "Home Address from
MNP" of RFC 4887 "Home Network Models".

> o  for V2V communication, i.e. when no infrastructure is available, 
> OBUs can use link-local addresses (default ones or with a C2C-CC 
> specific prefix TBD).  As described above, a portion of the VANET 
> (geographically or topologically scoped) is presented to IPv6 as a 
> single, link-local multicast link.  Therefore the link-local address 
> can be used for multi-hop communications within the VANET;

First, can there be an IPv6 link-local address with a prefix other than
fe80?  (as suggested above by "C2C-CC specific prefix TBD").   Shouldn't
this be agreed by the IPv6-related WG - or maybe that's why it's
mentioned TBD?

Second, what is understood by 'multi-hop communications'?  In my
understanding, 'multi-hop' is like Internet is multi-hop and IP
datagrams travel from hop to hop and have their TTL decremented at each
hop.  In this sense, if the VANET is presented to IPv6 a single
link-local multicast link then it is not multi-hop - the TTL is not
decremented throughout this link.

Third, whereas it is indeed possible to have two OBUs (On-Board Units,
MRs) to talk to each other by using their link-local addresses, it is
not possible for the AUs (Applicatin Units, LFNs) to talk to each other
even if their respective OBUs used their link-local addresses to talk to
each other.  In this sense, I wouldn't say "Therefore the link-local
address can be used for multi-hop communications within the VANET".

Can I simply suggest:

"Two OBUs can communicate directly through their respective egress
interfaces by using their IPv6 link-local addresses.  But their
respective AUs can not take advantage of this possibility."

Nit: 'divided' is better than 'devided', page 10.

Section 3.2.1 "System and Protocol Architecture" first paragraph
starting with "Vehicles are equipped with..." is identical to first
paragraph of page 7.  Possibly subsequent paragraphs are identical as
well.  I think it's redundant text between the C2C-CC and ISO CALM
sections.  The reader has already read the C2C-CC part, so now it would
make sense to simply state the differences.

Similarly, Figures 1 and 3 are almost identical, with the only
difference being the presence of an optional interface on OBU1.  It's
hard to spot that difference - better stress it in the text.

Figure 4 - what's 2G/3G GSM and CALM IR?  Whereas most acronyms in the
figure are explained ok in the text, these two aren't, and the reader
may need to have a grasp on these.   For example, is CALM IR Infra-red?

> This block comprises the NME (Network Management Entity) which is 
> able to interoperate with other layers in order to negociate priority
>  flow requirements

Nit: dot missing at the end of paragraph.

Also, what is NME (Network Management Entity)?  This is the sole time
this term is mentioned, and with its acronym - what does it mean, why is
it here?

> o  in order to avoid address resolution procedures, vehicles use only
>  IPv6 addresses with as host part an EUI-64 identifier derived from 
> the MAC address.  Privacy issues described in [...]

I think it would be better to say "Interface Identifier" instead of
'host part'.

At the same time, if we take figure 4 into consideration where 2G/3G GSM
networks are used instead of 802 networks, then MAC addresses are not
available, but Interface Identifier yes, if IPv6 with PPP is being used.
  Thus I could suggest a rephrasing if you agree.

> 2 types of globally routable IPv6 addresses: an IPv6 address 
> configured using standard IPv6 stateless address configuration from 
> Router Advertisements sent by RSUs connected to a network 
> infrastructure and an IPv6 address configured from a prefix 
> permanently allocated to the vehicle and delegated to the vehicle 
> from a home network.  The former globally routable IPv6 address is 
> used as the NEMO Care-of Address (CoA) and the latter as the NEMO 
> Home Address (HoA).

This again sounds as a duplicate of a paragraph on page 10, so my
remarks on that paragraph (cite section 5.3 of rfc4887) apply here as well.

> In addition, a self-generated IPv6 address with as prefix part a 
> pre-defined IPv6 prefix (either reserved for ISO CALM communications
>  or a general purpose one) may be used for ad-hoc communications with
>  other OBUs;

What does 'self-generated' mean?  A novel method of running
IPv6-over-foo method of generating addresses, like IPv6-over-CALM?  Or
using stateless autoconf?  Or using DHCP?  Maybe any of these three?
Maybe none of these three?

> o  RSUs can either act as IPv6 Access Routers or as bridges connected
>  to external IPv6 Access Routers.  Different Access Routers are 
> responsible for announcing different network prefixes with global 
> validity.  As a consequence, when roaming between different Access 
> Routers, vehicles experience layer 3 handovers.

This again sounds as copypaste of something I read earlier.  Is it
intentional?

> 4.4.  Vehicles Monitoring
> 
> Vehicles monitoring services allow car manufacturers, car garages and
>  other trusted parties to remotely monitor vehicle statistics.  Data 
> is collected by an AU and sent by the OBU to the service center via 
> the Internet.
> 
> As an example, car manufacturers or garages offering this service 
> could deploy NEMO Home Agents to serve thousands of cars.

I agree with the application and example use case.

However, I don't think NEMO protocol is adapted for this.  For example, 
in the above paragraph, was the intention to say that NEMO Home Agents 
will receive monitored data from the thousands of cars?  That's what is 
implied by the text.

The NEMO HA would only be involved in managing the mobility, and not in 
monitoring the data.  Another CN would be receiving the monitored data, 
from OBU (and probably from AU actually).  HA would be there simply to 
deal with the mobility of the OBU.

I am not sure what is the intention of the above paragraph, but I would 
clarify in order to avoid confusions of believing HA monitors data.

> 4.5.  Infotainment Applications
> 
>    TBD by ISO CALM
> 
> 4.6.  Navigation Services
> 
>    TBD by ISO CALM

I suppose this is to be defined?

>    The requirements defined in this document refer to RO between MR and
>    CE (Correspondent Entity).  According to the automotive use cases,
>    the CE can be:
> 
>    1.  Another vehicle, i.e. another automotive MR.

I suggest call it RO between MR and MR.  Or maybe RO between OBU and 
OBU.  But introducing the term CE is unnecessary.

>    In cases 1 and 2, the CE is a newly deployed entity.

It's not new, it's the MR, or the OBU.  BEtter call it MR or OBU, rather 
than CE.

Nit: 'occur' is better than 'occour'.

Nit: 'known in advance to the MR' is better than
      'known in advanced to the MR'

> 6.1.  Req 1 - Separability
> 
>    An RO technique, including its establishment procedure, MUST have the
>    ability to be enabled on a per-flow basis according to pre-defined
>    policies.  Policies criteria for the switching to RO MUST at least
>    include the end points' addresses and the MNP for which RO is to be
>    established.  Policies MAY change dynamically.
> 

Before Req 1 I would suggest Req 0 'Reusability' to reuse an existing 
protocol.

For req 1, I don't understand 'per-flow' - what's a flow?  Does it use 
the flow label in the IPv6 header?  Or is it another newly defined term?

Nit: 'This requirement' is better than 'This requirements'

Nit: 'unveil' or 'reveal' are both better than 'unveal'.

> 6.6.  Req 6 - Switching HA
> 
>    An RO technique MUST allow a MR to switch from one HA to another one
>    topologically distant from the first one.

This sounds either as an incomplete requirement (subsequent text doesn't 
  contribute to completeness, just to over-generalization) or as a 
non-requirement at all.

A requirement would be for MR to switch to another HA while keeping its 
existing HoAs and CoAs.  That is a requirement, probably difficult to 
satisfy.  I'd agree list it as requirement, but only if it were 
qualified by that 'keep its HoAs and CoAs'.

>    [c2ccc-manifesto]
>               "Car2Car Communication Consortium Manifesto",
>               http://www.car-2-car.org/index.php?id=570 , May 2007.

When I click on the link it says "TYP03 Error! The requested page does 
not exist!"

>    [calm-handbook]
>               "The CALM Handbook", http://www.calm.hu , May 2005.

I can't find a Handbook on this page - where is it more precisely? 
Thank you.

>    [ISO-21210-CALM-IPv6-Networking]
>               "Intelligent Transport Systems - Continuous air interface,
>               long and medium range (CALM) - Networking Protocols", ISO
>               Draft DIS 21210, February 2008.

Where is this document?

>    [ISO-21217-CALM-Architecture]
>               "Intelligent Transport Systems - Communications access for
>               land mobiles (CALM) - Architecture", ISO Draft DIS 21217,
>               June 2008.

Where is this document?

>    [IEEE.802-11p-d3-0]
>               "Draft Amendment to Standard for Information Technology .
>               Telecommunications and information exchange between
>               systems . Local and Metropolitan networks . Specific
>               requirements - Part 11: Wireless LAN Medium Access Control
>               (MAC) and Physical Layer (PHY) specifications: Amendment
>               3: Wireless Access in Vehicular Environments (WAVE)",
>               IEEE P802.11p/D1.0, February 2006.

Where is this document?

Thanks,

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext