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

[Abdussalam Baryun <[e-mail]>]

On Fri, Apr 12, 2019 at 6:32 PM Pascal Thubert (pthubert) <
[e-mail]> wrote:

> Hello Russ
>
> Right now the document doesn’t have a scope - It only says that the
> application and the link layer are not in scope which could be expected
> without saying.
>

not true. However, I agree with Russ, we need to follow the WG chair so we
can progress our work.


> This is what created a lot of confusion. An external reviewer cannot guess
> that there was an agreement on the ML to empty the doc from the substance
> that the title leads to expect.
>

IMHO, the title is clear, and understood, but you can suggest and we
discuss.


>
> The first step is probably for the authors to produce text giving that
> scope and then we can focus the review on exactly that. And adjust the
> title accordingly.
>

I hope you can work with us of the scope and suggestions.
I can suggest that we add text of IEEE1609,

IPv6 has provisions for neighbor discovery in which a Neighbor Cache is
populated with IP addresses

 and

associated MAC addresses of devices within communications range. This is
accomplished via a multicast

response mechanism, as specified in RFC 2461, and generates a substantial
amount of traffic on the

 channel. In some WAVE systems, it may be desirable to keep traffic on the
channel to a minimum,

 suggesting that the Neighbor Cache be populated via alternate methods such
as passive monitoring of over

the-air transmissions. Note that neighbor discovery per IETF RFC 2461 is
not precluded by the IEEE 1609

standards.

>
> I understand from Sri that ND should not be in scope at all.
>

I understand from Sri that ND is not precluded (as mentioned in IEEE1609)
but in WG other drafts we are considering developing for IPWAVE.


> Again there needs to be text in the scope for that. The current text
> still a section on subnets that leads to expect an ND discussion and more
> than 2 nodes.
>

ok can be modified,


> The latest discussion has clarified that if we stick to classical ND then
> only P2P subnets can be ensured (think like for ISDN) and even this
> requires an external method for DAD.
>

Not absolutely. In IPWAVE environment or in ITS it is not important
Neighbour  Discovery but the importance is Service Discovery, so the
application can change transmission power and can control the transmission
range and data rate. The WSMP is important in the RSU node and OBU node to
make the communication. The WAVE protocol send short WSA and WRA messages.


This restriction should be included in the scope. It is acceptable to
> reduce the scope but it is not acceptable to oversell ND for things it
> cannot do and was never supposed to do.
>

We can do without, but as mentioned by IEEE we can agree for now,
that  IETF RFC 2461 is not precluded by the IEEE 1609

>
> Whether global addresses and internet connectivity is in scope should also
> be detailed.
>

In IPWAVE environment both are in scope, why not in scope? Each service
provider has global address which is in WAVE unique ID. We don't forget
that any application-service can be IP based or non-IP based so the WAVE
advertises the address of the protocol identifier for such
application-service. We also don't forget that we may have other SDOs that
have different protocol/advertising technique for OCB links.


>
> On the side: Pretty much all the radios we deal with support at least hub
> and spoke. I thought it was of interest to build at least that.
>
> Initially and in the absence of Layer-3 support hub and spoke was
> permitted by an emulation at Layer-2 in a WiFi BSS. For all the others
> radios (e.g. Bluetooth or 15.4) and since the Layer-3 support now exists it
> is done using WiND. My knee jerk reaction when I reviewed the doc was to
> wonder why be so back level on OCB. But then if the use cases are only link
> local P2P then we can live without it.
>

It is not P2P without disconnection, usually when said P2P is means fixed
PHY layer not disconnected/dynamic-phy-link. The IPWAVE environment a high
speed Car-OBU is looking for services of short durations and it can get it
from many RSU sites because the transmission range is large and the Link
has many channels.


> I’ll try to write a draft or a paper on the different WLAN/WPAN subnet
> models and the applicability of rfc 8505 to build them but I cannot commit
> when.
>

That is for fixed networks and usually for building applications and
usually for Short Range of about less than 300 meters suitable for indoor
applications. This WG is doing Range of about 1 Km,  road traffic
safety and transportation applications.

AB