Re: [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34 - undocumented magic - cloud based channel allocation

[Alexandre Petrescu <[e-mail]>]

Le 09/04/2019 à 18:50, Pascal Thubert (pthubert) a écrit :
[...]
> I documented simple failure scenarios.  Like cars have duplicate 
> addresses but boot far away and then meet.

(I can tell you we worried about this boot-remote and then meet several
times in practice.

Because of that worry there is 'discovery' in the problem statement 
IPWAVE draft, please read it.

In practice we tried several times to boot cars far away and then meet;
it worked; maybe it worked because they never formed same address, or
because we used manually assigned pre-planned Link-Local addresses like
fe80:1::1/32 to be sure there is no conflict, but it worked.)

> Or they meet a common third party. The response I was given involves
> magic that is not documented.

The reasons why two cars boot-remote and then meet work ok are the 
following:
- both advertise RAs rapidly, in addition to responding to RSs.
- each self-forms an IPv6 LL out of its MAC address, which is a little
   bit, unique.
- to ensure more uniqueness we also use manually assigned link-local
   addresses, like fe80:1::1/32 between car 1 and 2, and fe80:2::1/32
   between car 2 and 3.

I am not sure which undocumented magic you refer to in what I said earlier.

I could remember I talked about channel setup between cars.

That may be considered as magic.

There is a need to assign the channels to interfaces in such a way to
avoid interference and maximize the closures.

In WiFi non-OCB this happens more or less automatically with intelligent
device drivers that listen to availability and the suggest to human
user some choices.  Also, some human planners of Access Point
deployments do make some choices by some algorithm of their preference,
to avoid overlaps, distribute nearby channels like 1-6-11 rather than 
1-2-3, etc.

This is sometimes called magic.  There is no standard of it.  It is like
when you make an IP addressing architecture for a large router deployment.

In OCB there there is no automation of how to set up channels between
cars and RSUs.  And there are not 11 channels, but just 5.  There is 
some recommendation of fixed allocation from regulators (e.g. use safety 
apps on Control Channel and use entertainment apps on Service Channel), 
but that is by no means an ultimate recommendation, nor is there a need 
to abide to it fully.  So people decide channels by some magic of their own.

My own magic for channel allocation could be described here.  It needs 
to have LTE access to a Internet cloud server that tells the cars their 
roles (leader, 1st follower, 2nd follower, etc).  But that would be 
another document, not IPv6-over-OCB.

Do you disagree with this direction?

Do you want just brief text about channel allocation in support of 
subnet formation in the OCB draft, in order to unmagic the magic? (not 
that is the first time I write it and risk disappear later).

Alex

> 
> Now, there are other scenarios that do not fail. So “doesn’t work “ 
> is an exaggeration. I said “does not cut it” and that means does not 
> pass a bar of satisfaction level where a basic function like DAD is 
> provided. The document should indicate what can be expected to work 
> satisfactorily and what needs more work. It must not give the 
> impression that ND is fully satisfactory and that the doc is the end 
> of it.
> 
> My proposed text indicates that at least DAD must be ensured some 
> other way because booting an interface with an ll address and doing 
> DAD at that time and forever is not s good model for the reasons I 
> indicated.
> 
> RFC 8505 is a great way to progress but I see that the WG needs time 
> to make up its mind. But it is reasonable to expect that the WG 
> considers the work done by peers that worked on similar space. The 
> document doesn’t mention it at all. There is space between 
> recommending and ignoring where we could find an agreement.
> 
> I also see that even if it helps a lot, RFC 8505 is not the end of
> it for OCB in particular when cars cross for a very short time. How
> do they know about each other? There must be some L3 beacon like a
> fast RA ala MIPv6. Is there a point resolving MAC addresses? Maybe
> unicast IP can just be sent over broadcast MAC. How do we do a DAD?
> Maybe an external Registry? Or just pseudo random numbers and
> statistical chances? What is a link where a link local must be
> unique, how do we build a subnet and defend addresses there?
> 
> All good questions that the doc doesn’t even approach. And there are 
> probably more. This is what I expect to find in an RFC called IPv6 
> over OCB.
> 
> The doc has interesting text about what is OCB that will be useful
> to do IPv6 over it, but it is not true to its title and doesn’t even 
> explain what the problems are before they can be solved. It doesn’t 
> say that covering that is not in scope either so it leaves the 
> impression of a done deal where all the difficult work is left to be 
> done.
> 
> At the end of the day I’m not clear why we want to publish it. Maybe 
> as an informational description of OCB to prepare for the work in
> the WG? I’d be fine with that but then the title should change.
> 
> All the best,
> 
> Pascal
> 
>> Le 10 avr. 2019 à 00:05, Suresh Krishnan <[e-mail]> a 
>> écrit :
>> 
>> Hi Pascal/Alex, Upleveling this a bit.
>> 
>>> On Apr 9, 2019, at 9:54 AM, Alexandre Petrescu 
>>> <[e-mail]> wrote:
>>> 
>>> 
>>> 
>>>> Le 09/04/2019 à 02:04, Pascal Thubert (pthubert) a écrit : 
>>>> Hello Carlos I think we’re a bit stuck. I spent really a long 
>>>> time explaining why RFC 4861 does not cut it
>>> 
>>> Pascal, with all due respect.
>>> 
>>> You seem to be claiming RFC4861 does not work on WiFi 
>>> altogether.
>>> 
>>> Is it so?
>> 
>> Pascal, we do know that RFC4861 ND *does* work on 802.11 OCB 
>> networks as witnessed by the several existing implementations. Of 
>> course, there are cases where it may may be sub optimal and this
>> is why I was fine with explaining some of the shortfalls with an 
>> informational pointer to RFC8505 (Thanks for helping with the 
>> text!! I think it provides a great overview). I personally do not 
>> think mandating RFC8505 is warranted at this point.
>> 
>> Thanks Suresh