Re: [Int-dir] [ipwave] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34

[Alexandre Petrescu <[e-mail]>]

I agree with you Sri.

It can make sense to write a separate ND spec for more variable 
environments, but not to delay the existing IP-over-OCB work.

ND in a gas station, ND between vehicles moving together, ND with car 
parked on parking, are just a fex examples where ND works fine on OCB.

Remark also that ND is not the only protocol on top of IP.

Alex

Le 14/04/2019 à 01:06, Sri Gundavelli (sgundave) a écrit :
> I understand your point Brian, but IMO there are enough reasons not to
> delay this work.
>
> There are many use-cases/applications where there is a stable topology of
> RSU¹s and OBU¹s. The regulations around 5.9 Ghz (DSRC) band allows the
> channel use for non-priority/non-traffic safety related applications. For
> example, a vehicle in a gas station can receive a coupon from the
> 802.11-OCB radio (AP/RSU) in the gas station. There, its a stable topology
> that classic ND is designed for. In this operating mode, its perfectly
> reasonable to use classic ND and it works. The authors have shown enough
> lab data on the same.
>
> Ideally, I agree with you that it makes lot more sense to publish both the
> specs at the same time. But, for what ever reasons the WG went on this
> path. Authors have spent incredible amount of efforts in getting the draft
> this far and we cannot ignore that. You can see the efforts from the
> version number; when did we last see a draft version -037?
>
> We also need to distill the recent ND discussions and filter out the
> threads that are clearly motivated to insert a ND protocol that is
> designed for a totally different operating environment. An argument that a
> protocol designed for low-power environments is the solution for vehicular
> environments requires some serious vetting. Looking at the
> characteristics, always-sleeping, occasional internet connectivity,
> low-power, no memory, no processing power, no mobility ..etc, meeting
> vehicular requirements is some thing most people in the WG do not get it.
>
> Bottom line, IMO, we should move this forward and publish the document.
> All we need is a simple statement in the spec which puts some scope
> limits, w.r.t the missing ND pieces and issues. There are other proposals
> in the WG that will address the gaps and bring closure to the work.
>
> Sri
>
>
>
>
>
>
>
>
>   
>
> On 4/12/19, 1:28 PM, "Brian E Carpenter" <[e-mail]>
> wrote:
>
>> On 13-Apr-19 02:59, Sri Gundavelli (sgundave) wrote:
>>> If you go back and check 2017 archives, I did raise many of these
>>> issues.  But, we clearly decided to limit the scope excluding address
>>> configuration, DAD, ND aspect, link models. When there is such a scope
>>> statement, it should clearly move these comments to the draft that
>>> defines how ND works for 802.11-OCB links.
>> This is of course possible. In general the IETF hasn't done that, but has
>> followed the lead set by RFC 2464 with the complete specification of
>> IPv6-over-foo in one document.
>>
>> However, I don't believe that publishing an RFC about the frame format
>> without *simultaneously* publishing an RFC about ND etc would be a good
>> idea. That would leave developers absolutely unable to write useful
>> code, and might easily lead to incompatible implementations. Since
>> we'd presumably like Fords to be able to communicate with Peugeots,
>> that seems like a bad idea.
>>
>> Regards
>>    Brian
>