Re: [ipwave] RFC8505 and 802.11 headers

[Pascal Thubert <[e-mail]>]

Hello Alexandre;

When should an OCB node do a DAD?
What guarantee do you expect from it?
In particular what set of nodes do you trust will not have a collision?

As I indicated in my review you have to define the link (who is in) and the subnet for link local and global addresses respectively.

Multicast works well for ND if it provides a consistent permanent reliable connectivity between the members of the link/subnet.
When you do not have that you can not claim that multicast works (for ND).

Example: 2 cars form a same link local address when not in range from one another. Is that detected? Then say they meet. Can they talk? What does a RSU do when in range of both?

RFC 8505 takes care of that issue among others. Like the fact that multicast is less reliable than unicast. It has nothing to do with low power and everything to do with the MAC layer and ARQ procedures which are similar in the IEEE protocols we are discussing.

The draft misses explanations on the above and a broad claim that multicast and thus ND just work is not technically correct.

Cheers,

Pascal

> Le 8 avr. 2019 à 04:00, Pascal Thubert <[e-mail]> a écrit :
> 
> Hello Sri
> 
> I already suggested to stop confusing RFC 8505 with 6LoWPAN. The RFC has its applicability section which does not limit it to that but rather considers whether multicast is available or not.
> 
> Focusing on 6LoWPAN doesn’t help; what helps is understanding the properties of the protocol and the type of connectivity one gets in a vehicle and then consider the matching.
> 
> For the rest I mostly agree with you.
> 
> All the best,
> 
> Pascal
> 
>> Le 8 avr. 2019 à 01:38, Sri Gundavelli (sgundave) <[e-mail]> a écrit :
>> 
>> > The group may not yet fully understand why RFC 8505 is suitable for the job but at least we all understand that RFC 4861 is not, based on the own words in the RFC.
>> 
>> I am fine with the author's assertion that 8505 is a great fit, but the authors have to establish that. I am sympathetic to that view that it can be used, but I cannot take that at its face value.
>> 
>> If I look at RFC 4919 (6LoWPANs: Overview, Assumptions, Problem Statement, and Goals), section 2, where it provides a definition of LoWPAN network, I do not think it includes all the properties of a vehicular network. Vehicular network is about mobility, latency, always-on-connectivity. Latency is one important property which is not even a consideration for low-power devices. The vehicle may be running on a battery, but the stringent low-power constraint may not be applicable for WAVE environments; The compute power available in the vehicle does not put a strict constraints on processing powers, or memory as it does for certain IOT devices.  
>> 
>> Therefore, the below text does not make me believe the designers of 6LOWPAN had vehicular networks in mind.  At the same time, I do agree some of the principles may be applicable here and leveraged for IPWAVE, but I cannot agree that this is perfect fit and was designed exactly for this operating environment as I read from this thread.
>> 
>> 
>> —————
>> RFC 4919: Section 2
>> 
>> A LoWPAN is a simple low cost communication network that allows
>> wireless connectivity in applications with limited power and relaxed
>> throughput requirements. A LoWPAN typically includes devices that
>> work together to connect the physical environment to real-world
>> applications, e.g., wireless sensors. LoWPANs conform to the IEEE
>> 802.15.4-2003 standard [IEEE802.15.4].
>> 
>> Some of the characteristics of LoWPANs are as follows:
>> 
>> 1. Small packet size. Given that the maximum physical layer packet
>> is 127 bytes, the resulting maximum frame size at the media
>> access control layer is 102 octets. Link-layer security imposes
>> further overhead, which in the maximum case (21 octets of
>> overhead in the AES-CCM-128 case, versus 9 and 13 for AES-CCM-32
>> and AES-CCM-64, respectively), leaves 81 octets for data
>> packets.
>> 
>> 2. Support for both 16-bit short or IEEE 64-bit extended media
>> access control addresses.
>> 
>> 3. Low bandwidth. Data rates of 250 kbps, 40 kbps, and 20 kbps for
>> each of the currently defined physical layers (2.4 GHz, 915 MHz,
>> and 868 MHz, respectively).
>> 
>> 4. Topologies include star and mesh operation.
>> 
>> 5. Low power. Typically, some or all devices are battery operated.
>> 
>> 6. Low cost. These devices are typically associated with sensors,
>> switches, etc. This drives some of the other characteristics
>> such as low processing, low memory, etc. Numerical values for
>> "low" elided on purpose since costs tend to change over time.
>> 
>> 7. Large number of devices expected to be deployed during the
>> lifetime of the technology. This number is expected to dwarf
>> the number of deployed personal computers, for example.
>> 
>> 8. Location of the devices is typically not predefined, as they
>> tend to be deployed in an ad-hoc fashion. Furthermore,
>> sometimes the location of these devices may not be easily
>> accessible. Additionally, these devices may move to new
>> locations.
>> 
>> 9. Devices within LoWPANs tend to be unreliable due to variety of
>> reasons: uncertain radio connectivity, battery drain, device
>> lockups, physical tampering, etc.
>> 
>> 10. In many environments, devices connected to a LoWPAN may sleep
>> for long periods of time in order to conserve energy, and are
>> unable to communicate during these sleep periods.
>> 
>> ----------
>> 
>> 
>> 
>> 
>> 
>> On 4/7/19, 3:19 AM, "Pascal Thubert" <[e-mail]> wrote:
>> 
>> Then let’s not use an old hammer when screws have replaced nails!
>> 
>> I understand the piece where you claim that the group did not get a chance to evaluate RFC 8505 on OCB.
>> 
>> The group may not yet fully understand why RFC 8505 is suitable for the job but at least we all understand that RFC 4861 is not, based on the own words in the RFC.
>> 
>> You may decide not to mention ND at all. But what’s left in the spec?
>> 
>> Pascal
>> 
>> Le 7 avr. 2019 à 00:08, Sri Gundavelli (sgundave) <[e-mail]> a écrit :
>> Hello Charlie,
>> If I may comment on this thread.
>> I do not want to blindly assume that RFC 8505 was designed for vehicular
>> environments and that all the properties of low-power lossy networks are
>> the only relevant attributes of a vehicular network. While the ideas in
>> RFC 8505 may be applicable here, I do not think its a good idea to
>> mandate/recommend RFC 8505 as the solution for this work, without
>> establishing that.
>> There are two issues here. This is a procedural aspect here where we
>> clearly decided not to bring ND solutions into this draft and we are doing
>> that now after post IETC LC, which I strongly object. The other thing is
>> lack of technical analysis before we insist that 8505 must be applied for
>> IPWAVE environments. While, I do agree with you, we should refrain from
>> designing new protocols for every variant of wireless networks, but its
>> also incorrect to take the view of using a single hammer for everything.
>> Sri
>> On 4/6/19, 8:42 AM, "its on behalf of Charlie Perkins"
>> <[e-mail] on behalf of [e-mail]> wrote:
>> Hello Carsten,
>> RFC 4861 was completed long before the IETF and IESG had a more complete
>> understanding of the issues surrounding wireless multicast. Pascal is
>> correct that RFC 8505 is not intended to be restricted to WPAN or WiFi.
>> And it would be wrong to require, for each type "foo" of wireless
>> medium, a separate "ND-over-foo" document, when the issues are general
>> to wireless and not specific to "foo".
>> I hope that anyone reading this thread would also consider reading
>> [draft-ietf-mboned-ieee802-mcast-problems] which is heading for WG Last
>> Call soon.
>> Regards,
>> Charlie P.
>> On 4/6/2019 8:28 AM, Carsten Bormann wrote:
>> RFC 4861 says:
>>     Unless specified otherwise (in a document that covers operating IP
>>     over a particular link type) this document applies to all link
>> types.
>> So it is the job of an IP-over-foo document to say whether ND-classic
>> applies or a variant form that works better over wireless.
>> We had extensive amount of discussions and we agreed to keep ND
>> support out of scope for this document, and that separate document will
>> address those ND issues.
>> You can do that, but RFC 4861 does not leave you the option of not
>> addressing the issue of whether ND-classic applies unchanged.
>> Any discussions around ND in this document will be limited to issue
>> identification and not about solutions. That was the agreement in the
>> WG and so I am failing to understand why we are departing from that and
>> bringing RFC 8505 discussions into this  and post IETF last call.
>> Maybe that consensus was reached without a close reading of RFC 4861?
>> _______________________________________________
>> its mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/its
>>