Re: [Tsv-art] Tsvart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46

[Alexandre Petrescu <[e-mail]>]

note: my text is an explanation of how I see things.  I am not an author 
of the OCB document.  The OCB document has an Editor, and it belongs to 
the WG IPWAVE.

Alex

Le 05/07/2019 à 13:15, Alexandre Petrescu a écrit :
>
>
> Le 27/06/2019 à 18:38, Joerg Ott via Datatracker a écrit :
> [...]
>> App. E: why would high mobility affect encapsulation"?
>
> The paragraph in question is this:
>>
>> Appendix E.  Design Considerations
>>
>> The networks defined by 802.11-OCB are in many ways similar to other 
>> networks of the 802.11 family.  In theory, the encapsulation of IPv6 
>> over 802.11-OCB could be very similar to the operation of IPv6 over 
>> other networks of the 802.11 family. However, the high mobility, 
>> strong link asymmetry and very short connection makes the 802.11-OCB 
>> link significantly different from other 802.11 networks.  Also, the 
>> automotive applications have specific requirements for reliability, 
>> security and privacy, which further add to the particularity of the 
>> 802.11-OCB link.
>
> There a huge list of Design Considerations in the main matter. More and
> more reviews led to skinning it to just one paragraph, depicted above.
>
> Let me try to answer to the question of why would high mobility affect 
> encapsulation.
>
> First, the word encapsulation seems to have captured your attention.  
> I hope it is for a good reason, but frankly speaking I do not know the 
> reason why it attracted it.  To clarify, let me say that the word 
> 'encapsulation' was used to signify 'carrying' IPv6 datagrams on 
> 802.11-OCB.  One expects IPv6 to be carried over OCB as over WiFi. 
> ('encapsulation' was not used to mean IPv6-in-IPv6 encapsulation and 
> friends).
>
> The high mobility in OCB is contrasted to low (or no) mobility in WiFi 
> - it means that in WiFi users are near a fixed Access Point and dont 
> move much.  But in OCB there are no access points and cars move a lot.
>
> High mobility in OCB may need to avoid potential interference in order
> to ensure safety.  TO achieve that, it may be possible that QoS concents
> become more mandatory on OCB links (than on WiFi; on WiFi the QoS
> concepts are almost absent in implementations).  Thus, there may be a
> need of some mapping between IPv6 QoS-specific fields and 802.11-OCB 
> QoS-specific fields.  There may be need of other QoS-specific fields.
>
> So, whereas an IPv6-over-WiFi spec (which does not exist, btw) has no 
> mapping of QoS fields of how  IPv6 is 'carried' (encapsulated) on 
> WiFi, an IPv6-over-OCB would need some mapping of this sort, so that 
> IPv6 is better 'carried' over OCB.  Because of mobility.
>
> QoS is just an example of why encapsulating (carrying) IPv6 on OCB may 
> need more than just what is needed by carring IPv6 on WiFi.
>
> There are other examples: IPv6 addressing in OCB links requires human 
> intervention often - it's not as plug and play as IPv6 over WiFi.  
> That needs easy to remember and subnet-specific link local addresses, 
> like fe80:1::1/32.  These addresses dont exist on IPv6 altogher, let 
> alone IPv6-over-WiFi.
>
> There are more examples.
>
> Remark my own difficulty  of speculating on something which does not 
> exist: IPv6 over WiFi specification.
>
> Alex