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

Dear Roberto,

Thank you for the email.  See below a few further comments.  The parts 
I've silently snipped are ok with me.

Roberto Baldessari wrote:
>> 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.
> 
> Good point. What needs to be specified is IPv6-over-C2CNET (see 
> Figure 2). In fact ETSI TC ITS WG 3 is going to write the standard 
> for the geonetworking protocol that provides non-IP geographic ad-hoc
>  routing. In ETSI, a work item for the specification of 
> IPv6-over-geonetworking (Title: Intelligent Transport System (ITS); 
> Transport & Network; Integration of IPv6 and GeoNetworking) has 
> already been assigned. I am the "rapporteur". The ETSI document 
> should also be followed-up by an IETF I-D. The ETSI drafts need to be
>  stable first. A stable ETSI draft is due by Nov 2009. But that 
> activity does not affect this requirements draft.
> 
> Regarding IPv6-over-11p, nothing needs to be specified as 11p does 
> not amend changes to 802.11 as far as this is concerned. The same 
> mechanism as for 802.11 apply (802.11+802.2+SNAP).

It is good to note the same IPv6 mechanism for 802.11
(802.11+802.2+SNAP) applies to IPv6 over 802.11p.

I think this assumption is worth noting in the draft.

Yet I have some doubts about the use of ND over 802.11p.

One reason of my doubts is because the 802.11p draft I can access is not
the latest - maybe things changed.  I'm using "IEEE Trial-Use Standard
for Wireless Access in Vehicular Environments (WAVE)—Networking
Services" 20 IEEE Std 1609.3™-2007 20 April 2007.  I'm not even sure
whether that's what we mean by "802.11p".

This document has explicit assumptions on the use of IPv6.  Among
others, for example, section 4.5 "IPv6 Neighbor Cache" makes explicit
assumptions about how the NC is filled with addresses.  It is stated,
for example : "... so alternate methods for generating the Neighbor
Cache are defined. Note that neighbor discovery is not precluded in
cases where it might be needed."

It would probably be appropriate for a MEXT method achieving direct
paths ("RO"?) between two vehicular MRs without infrastructure - to say
that "if ND is needed with these P1609.3 systems, ND is used in this and
that way".

You may wonder why I'm talking ND here.  I do so at least because Mobile
IPv6 and NEMOv6 do talk ND at some point.  So this could be pertinent.

>> 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.
>> 
> 
> You're right, the definition is missing. Among the authors we did not
>  have 100% consensus on this term. The terms 'V2V' and 'V2I' are used
>  in many automotive documents to distinguish whether or not the 
> infrastructure is involved. So V2I2V can be seen as part of V2I, 
> according to this criterion and therefore I think the term can be 
> removed (in fact it only appears in the second part). We'll rediscuss
>  this point.

Ah I see... the point of V2I2V being actually two times a V2I makes
sense to me.  This explanation could be added when the term V2I2V is
mentioned first.  Or it could be discussed further.

>> 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".
>> 
> 
> Thanks for pointing this out. In fact, this may be an unwanted 
> restriction due to misphrasing. IMO there is no particular reason 
> related to the automotive use cases for which the HoA should be 
> derived from the MNP.

I agree.

>>> 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?
>> 
> 
> Right. We tried to be as general as possible in these first versions
>  of the draft. But it's unlikely that the automotive industry will 
> really need a (additional) link-local unicast prefix different than 
> fe80::/10.

I agree.

>> 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.
>> 
> 
> Multi-hop in the draft is not necessarily referred to IP. Since this
>  is an IETF draft, I see your point. If a non-IP protocol is used, 
> then multi-hop communication should be called differently. We'll try
>  to improve this.

I agree, thank you.  Maybe describing link-layer multi-hops as not
decrementing the Hop Limit field in the IPv6 base header (akin to IPv4 
TTL) could do.  Anyways, defining link behaviour in terms of what 
happens to Hop Limit is easily understood often, I think.

>> 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".
>> 
> 
> See the previous observation. In the text, OBU to OBU (not involving
>  AUs) via several non-IP hops is still called multi-hop. This 
> generates confusion. We need to improve the text as to usage of 
> terms.

Thanks, I agree.

>> 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."
>> 
> 
> Well, correct observation but maybe not in the scope of the doc. 
> Please note that we tried to restrict the scope of requirements to 
> the ones related to Route Optimization for NEMO BS, therefore 
> infrastructure-based. The automotive industry needs more than this, 
> no doubt. But MEXT does not seem to be the right place for that. I 
> was involved in the MANEMO discussion but in the end I agreed with 
> the objections on scopes.
> 
> Solutions for IPv6 AU-to-AU (note that I don't use MNN-to-MNN on 
> purpose) infrastructure-less are needed. But this draft can not 
> target them. We can still point this out in the draft and say that 
> it's out of scope.

I see what you mean, as a scoping problem.  Explicitly leaving vehicular
MR-to-MR infrastructure-less RO out of scope of this document would be 
then fine with me too.

>>> 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.
>> 
> 
> Newly deployed means that we have more design freedom as compared to
>  legacy IPv6 nodes. I think the distinction is important. You might 
> want to suggest a different terminology.

Whereas I agree with you a CE may be new compared to an 
IPv6-but-non-NEMOv6 Mobile Router, I don't agree CE is new compared to a 
NEMOv6 Mobile Router.  It's difficult to understand what new means here.

CE is a new term indeed, but it designates an existing MR plus RO
_sometimes_.

>>> 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.
>> 
> 
> Please elaborate.

Thanks for asking.  I meant to say something about the necessity to
re-use an existing protocol.  This could be Mobile IPv6 and/or ND.
NEMOv6 is not a protocol per se, but an extension to Mobile IPv6.  In
this sense, the requirements would better be better scoped, (1)
eliminating the possibility of designing, for example, an UDP-based
message exchange for security credentials (maybe IKE) to achieve optimal
paths.  And also eliminating any new exchange designed out of nothing,
like for example an xml-based http exchange for achieving same goals.

>> 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?
>> 
> 
> Flow is used in so many RFCs without defining it. Even RFC 2460 
> defines Flow Labeling Capability without defining what a flow is (Sec
>  1). Did I maybe miss the RFC where the term flow is defined?

I think flow has many different co-notations and the only formally
implemented is the Flow Label.  This draft's per-flow
behaviour doesn't assume flow labels because, for example, it says at
some point:
> The IP version 6 is the version considered for IP types of flows. [datagrams?]
and later on
> a particular IPv6 flow [a flow label?]

I'm not trying to confuse anybody, but it is confusing to me.  Or maybe 
some readers can easily disambiguate these occurences.

>>> [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!"
> 
> 
> The C2C-CC website has just been redone. This is the new link: 
> http://www.car-2-car.org/fileadmin/downloads/C2C-CC_manifesto_v1.1.pdf

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