Re: [Efficientnd-dt] Update to dad-issues draft

[Erik Nordmark <[e-mail]>]

On 2/26/15 11:59 PM, Eric Vyncke (evyncke) wrote:
> Erik and Andrew,
>
> Some quick comments:
> - in intro: add xref to RFC 2460, worth to copy the description of DAD
> mechanism in your document if not too long? Also introduce the DAD acronym
> early in the intro

Eric,
Thanks for your comments.

DAD is described in 2462. What do we need to cite from 2460?
I'll add a short description of DAD and expand the acronym.
> - 2.3 should explicitly mention wireless? Should mention the I-D regarding
> the use/abuse of mcast traffic by NDP?
2.3 is about Partition-join tolerance. I don't know if there are 
specific partition issues for wireless that are worth mentioning.

Section 2.2 is about the packet loss. We should add a reference in 2.2  
- mcast-not-efficient makes sense. Did you have some additional draft in 
mind?

Should we add a reference to 
draft-desmouceaux-ipv6-mcast-wifi-power-usage? That was more about power 
consumption AFAIR. I'll add a reference to that draft in the efficiency 
section.
> - I like the classification by groups of issues rather than the long list
> - 3.2 in case of duplicate address, not only TCP is impacted. If the new
> host (with colliding address) does not listen on UDP port X while the old
> one does, then ICMP port unreachable will be sent which could have
> undesirable consequences
Agreed.

While other protocols can be affected, the description of this is more 
subtle. If the new host sends a packet to some peer the response will go 
back to the old host, which as you say might generate an error. Some 
protocols like a DNS lookup doesn't care about those unreachables. But 
an application layer protocol using UDP which creates or modifies some 
state when it receives the packet from the next host might cause 
failures for the old host's communication. The optimistic DAD draft 
doesn't go into those details, and it is a bit of a tangent for this draft.

Thus I don't want to go into all those details in this draft. I could be 
convinced to add some vague language like
     "Other protocols which manage state like TCP create could also be 
affected."

> - 4.3 readability/clarity could be improved, esp paragraph 4

That is the paragraph about NBMA. I think Andrew added that. I don't 
know if we'd view a multi-link subnet as an NBMA link since each link is 
still broadcast, while the subnet would not have a notion of a 
link-layer broadcast.

A WiFi link and subnet with blocked host-to-host communication is 
different again; there is a subnet prefix assigned to the link, and 
link-local broadcast/multicast can be used for some communication paths 
(e.g., a router can send to all-nodes multicast and it will get through, 
but a host's multicasts will be filtered.)

Perhaps we should preface this with some more explanatory text, and also 
rename the section to be about "odd links" which includes
  - multi-link subnets
  - NBMA links
  - filtering host-to-host communication on a link
With such a prelude, would things be more clear? Or are there specific 
clarifications in para 4 that would fix it?

> - 4.5 s/anywhere/anyway/ ?
Will fix.

Thanks again
    Erik

>
> Hope it helps
>
> -éric
>
>
> On 27/02/15 07:52, "Erik Nordmark" <[e-mail]> wrote:
>
>> Andrew and I have made some updates to the dad-issues draft, mainly to
>> order the list to make it more clear which issues remain, which are
>> already (being) solved and which are more observations about DAD.
>>
>> Comments welcome,
>>      Erik
>>
> _______________________________________________
> Efficientnd-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/efficientnd-dt
>