Subject: [ipwave] OCB draft wording for ND and mobile-IP

From: Erik Nordmark <[email-masked]>
Date: Mon, 5 Nov 2018 20:54:43 -0800

Nabil,

CURRENT:
    The Neighbor Discovery protocol (ND) [RFC4861] is used over
    802.11-OCB links.  The reliability of the ND protocol over 802.11-OCB
    is the reliability of the delivery of ND multicast messages.  This
    reliability is the same as the reliability of delivery of ND
    multicast messages over 802.11 links operated with a BSS ID.

SUGGESTED:
    The Neighbor Discovery protocol (ND) [RFC4861] is used over
    802.11-OCB links.  Due to lack of associations in 802.11-OCB
    unicast has the same reliability as multicast. The ND
    retransmissions are supposed to handle loss of unicast and multicast
    just as it does on 802.11 BSS.

Note that in mail 
https://mailarchive.ietf.org/arch/msg/ipv6/jVc5zmJ5MOOQ0jHlWAv2UQP3loE 
Brian points out that the subsequent paragraph is now broken.

Since the document doesn't specify use of mobile IP you might be able to 
just drop that subsequent paragraph.
If you think it is required to keep it I think the correct statement is 
more complex as follows:
Section 11.5.1 of [RFC6275] does not rely on link-layer notifications 
but on the advertisement interval and NUD, both of which work for OCB.

However, and I really don't think we need to add this to the draft, 
DNAv6 [rfc6059] assumes link-layer notification [rfc4957] for quick 
movement detection. If folks want to use DNAv6, then
  - Tuning ReachableTime and/or the default router lifetime can
    ensure that old nodes and default routers are marked as unreachable
    or deleted more quickly.
  - Tuning RA advertisement interval down can ensure that new default
    routers are detected more timely.
But as I said, I think it is best to remove the confusing Mobile IP text 
(and not add anything about DNAv6).

Regards,
    Erik

---

From: Nabil Benamar <[email-masked]>
Date: Tue, 6 Nov 2018 12:18:51 +0700

Thank you, Erik, for your prompt comments!

I agree on the suggested changes related to unicast and multicast since
both have the same reliability!

Also, the mentioned paragraph about mobile IP can be removed after
discussion with co-authors.

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 5 Nov 2018 23:01:49 -0800

On 11/5/18 21:37, Dick Roy wrote:
> What you both may be assuming is that the RF environment for both is 
> statistically similar, while in many “OCB” scenarios, nothing could be 
> farther from the truth.  When network topologies are changing every 1 
> millisecond, it’s not so simple.

Dick,

FWIW I'm not making that assumption.

The RF environment is not a function of OCB vs BSS, but is a function of 
the deployment and use case.

    Erik

> 
> Best of luck … let me know how it turns out.
> 
> RR
> 
> ------------------------------------------------------------------------
> 
> *From:*its [mailto:[email-masked]] *On Behalf Of *Nabil Benamar
> *Sent:* Monday, November 5, 2018 9:19 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [ipwave] OCB draft wording for ND and mobile-IP
> 
> On Tue, Nov 6, 2018 at 11:54 AM Erik Nordmark <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Nabil,
> 
>     CURRENT:

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 7 Nov 2018 18:01:25 -0800

[I don't think this made it to the list]

 >     just as it does on 802.11 BSS.

It was suggested to instead refer to lack of link-layer acknowledgements 
instead of associations hence I'd change the above suggestion to:

    The Neighbor Discovery protocol (ND) [RFC4861] is used over
    802.11-OCB links.  Due to lack of link-layer acknowledgements in
    802.11-OCB for both unicast and multicast, we can expect higher
    unicast loss than for 802.11 BSS. The ND retransmissions are supposed
    to handle loss of unicast and/or multicast
    just as it does for other link types.

The subsequent mobile ip paragraph could be replaced by a more accurate 
statement like:

Protocols like Mobile IPv6 and DNAv6 [rfc6059] which depend on timely 
movement detection might need additional tuning work to handle the lack 
of link-layer notifications during handover. This is for further study.

    Erik