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

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

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.

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

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.

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

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. 

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

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

Best regards,

Roberto
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext