Re: Request for 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22

[Alexandre Petrescu <[e-mail]>]

Le 17/06/2018 à 03:39, Brian E Carpenter a écrit :
> On 17/06/2018 05:28, Alexandre Petrescu wrote:
>>
>>
>> Le 16/06/2018 à 15:02, Michael Richardson a écrit :
>>> [SECURITE : MISE EN QUARANTAINE DES PIECES JOINTES POTENTIELLEMENT DANGEREUSES]
>>>
>>> Ce message contient des pieces jointes potentiellement dangereuses car susceptibles de contenir des virus. Pour lutter contre l'expansion de ce type d'attaque, les documents [null] ont ete retires du message original ci-dessous. Pour les documents Office, le CEA recommande l'usage exclusif des formats plus recents exempts de macros comme DOCX, XLSX, PPTX, merci de le signaler a votre expediteur.
>>>
>>> Pour de plus amples informations ou pour connaitre les mecanismes de mise en quarantaine, vous pouvez vous rapprocher de votre service informatique ou consulter le site USCIpedia - rubrique PureMessage.
>>>
>>> ----------------MESSAGE ORGINAL ci-dessous------------------
>>>
>>>
>>> Brian E Carpenter <[e-mail]> wrote:
>>>       >>> On Jun 15, 2018, at 5:12 AM, Alexandre Petrescu <[e-mail]> wrote:
>>>       >>>
>>>       >>> But, we do not know whether a regular android smartphone can work in OCB mode.
>>>       >>>
>>>       >>> That is a key point of ND over OCB.
>>>       >>
>>>       >>
>>>       >> Why are we blocking progress due to one implementation?
>>>
>>>       > Well, the fact that the explanation of how ND and SLAAC actually work
>>>       > on OCB is incomplete is really what's blocking progress. Alexandre
>>>       > has said that ND has been observed to work (he didn't mention SLAAC,
>>>       > but I guess it must have worked too). But I still can't reconcile that
>>>       > with the explanation that OCB nodes missing packets is a normal, rather
>>>       > than exceptional, situation. How does ND work when there's a radio-frequency
>>>       > barrier between two nodes?
>>>
>>> It sounds like they need to profile RFC6775 or
>>> https://datatracker.ietf.org/doc/draft-ietf-6lo-rfc6775-update/
>>
>> If we want to profile something, we would need first to have a problem.
>> What is the problem?
> 
> How does ND work when there's a radio-frequency barrier between two nodes?

A PHY barrier will be avoided with a PHY mirror.  In some context people 
put PHY mirrors in the middle of the intersection.  In others the 
mirrors are naturally on the building walls along the road.  It is also 
possible that there are no PHY mirrors, at which point ND will break. 
Because neither multicast nor unicast work when there are PHY barriers.

Is RFC6775 offering PHY mirrors?

(a PHY mirror is like the disco club mirrors on globe for IrDA 
technology; for 5.9GHz it is a Road-Side Unit with a repeating bridge)

Alex
>   
>     Brian
> 
> 
>>
>> As a side note, for my part I do not approach RFC6775 "Registration
>> Extensions for 6LoWPAN Neighbor Discovery" because OCB is not 6lowPAN.
>>
>> These two technologies are very much different: different frequencies,
>> ranges, application goals and more.  Nobody thinks of using 6lowpan to
>> communicate between moving cars.  You could if you wanted to play, but
>> not sure why.  It's like working on ATM and somebody points rather to FDDI.
>>
>> Ironical: of course, we could also block an RFC because it does not
>> refer to all other RFCs.  Irony ended.
>>
>> Alex
>>
>>>
>>> They solve ND when broadcast is not complete.
>>> However, they depend upon having a deice to keep track of things.
>>> That it turn is facilitated (but not required) by having a routing protocol
>>> that creates an DAG and creates an up direction which makes it obvious
>>> where the DAR/DAC packets go to/come-from.
>>>
>>> This might be a problem in a regularly changing convoy, but shouldn't be a
>>> problem within a vehicle.
>>>
>>> --
>>> Michael Richardson <[e-mail]>, Sandelman Software Works
>>>    -= IPv6 IoT consulting =-
>>>
>>>
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 
>