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

From: "Roberto Baldessari" <[email-masked]>
Date: Mon, 1 Dec 2008 16:35:16 +0100

Dear Alex,

Thank you very much for your comments. Please see inline. 

> 
> 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).

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

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

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

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

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

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

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

Right, the next step will most likely be merging the sections (we need consensus from the involved bodies)

[can't comment on CALM-related issues, sorry]

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

Yes, that's what we meant. The HA is not necessarily the entity that offers the application service. We can clarify this. 

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

Already addressed by Thierry. We followed RFC 4885.

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

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

Please elaborate.

> 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?

> 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'.

Agreed. CALM needs to clarify.

> 
> >    [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

> 
> >    [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?
> 

IEEE drafts are only available for IEEE members.

Best regards,

Roberto
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 01 Dec 2008 20:29:31 +0100

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:
>> 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.

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

>> 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_.

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

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", 
>> When I click on the link it says "TYP03 Error! The requested page 
>> does not exist!"
> 
> 

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
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Roberto Baldessari" <[email-masked]>
Date: Wed, 3 Dec 2008 11:09:13 +0100

Dear Alex, 

> > 
> > 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 
> 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(tm)-2007 20 April 2007.  I'm not even sure whether that's 
> what we mean by "802.11p".
> 

IEEE 802.11p and IEEE 1609.X are two separate standard drafts. The 1609 family specifies additional protocols (WSMP) and mechanisms to be used on top/in combination of/with 802.11p. In Europe 1609 does not have much consensus for various reasons. ETSI is likely to make a profile of 802.11p and redefine some functionalities that are offered by 1609 but in a different way.
Further, 11p and 1609 are going to change. The latest 11p version is D4.02, Sept 2008. Many amendments have been removed. So 11p will be very similar to a 11a 'pseudo ad-hoc' mode.

To cut the story short, 1609 is not assumed in the draft. Feel free to contact me offline if you need more info (I feel we're getting out of scope of this ML).

> 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".
> 

Concerning NEMO BS RO requirements, I currently don't see the need for specific requirements on ND. Whereas concerning the specification of IPv6-over-ETSIgeonetworking ND should be discussed. ND extensions you probably have in mind are in the scope of those specifications rather than here.

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

Agreed.

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

we'll come up with something like this.

> NEMOv6 Mobile Router.  It's difficult to understand what new 

non-NEMOv6 Mobile Router is out of scope here. Some may say it is an oxymoron
RFC 4885 does not say MR neessarily runs NEMO BS. But the scope of the draft is NEMO BS RO.
Regarding the CE see below.

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

I don't agree with the last sentence. According to RFC 4885, CE is either CR (NEMOv6-RO-enabled NEMOv6 MR) or a CN, which can be either a plain IPv6 host or a NEMOv6-RO-enabled IPv6 host.
In fact RFC 4885 defines CN as "Any node that is communicating with one or more MNNs". For this reason I think CE is appropriate, because is the most general term you could use.

Newly deployed CEs simply means CEs that can be deployed together with the NEMO RO mechanisms that is the subject of requirements. If this is not clear we can add some text.

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

I think reusage of existing protocols is always required in IETF. I'm not convinced we need to write this explicitely. 

> Does it use 
> >> the flow label in the IPv6 header?  Or is it another newly defined 
> >> term?
> >> 
> > 
> 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:
> I'm not trying to confuse anybody, but it is confusing to me. 
>  Or maybe some readers can easily disambiguate these occurences.
> 

Got the point. We'll try to clarify it.

Best regards,

Roberto

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 05 Dec 2008 16:58:50 +0100

Dear Roberto,

[...]
> IEEE 802.11p and IEEE 1609.X are two separate standard drafts. The
> 1609 family specifies additional protocols (WSMP) and mechanisms to
> be used on top/in combination of/with 802.11p. In Europe 1609 does
> not have much consensus for various reasons. ETSI is likely to make a
> profile of 802.11p and redefine some functionalities that are offered
> by 1609 but in a different way. Further, 11p and 1609 are going to
> change. The latest 11p version is D4.02, Sept 2008.

Please send me in private 11p D4.02 dated September 2008.

> To cut the story short, 1609 is not assumed in the draft. Feel free
> to contact me offline if you need more info (I feel we're getting out
> of scope of this ML).

I need to identify precisely what can be done in IETF MEXT about: 1609, 
11p and ETSI European Profile.

I will contact you in private about these documents.

Alex