Summary of comments from adoption call of draft-chakrabarti-nordmark-6man-efficient-nd-04

[Samita Chakrabarti <[e-mail]>]

Hello All:

We have  had  lively and interesting discussions on the mailing list on  efficient-nd.

Here is a  summary gathered from various discussion threads:

As of January 15, 2014 on the adoption call, here are some numbers:

1.       Support (10 including co-authors)

2.       No support or no need of such work (3)

3.       Comments and suggestions  for updates (4) [ Eric Vyncke, Andrew Y, Mark ZZZ, Michael Abrahamson]



In general : Better problem statement and simplification/clarification/improvement is needed. There are multiple folks who commented that such work is needed.



Draft-ietf-6man-resilient-rs context:
It in fact has  a different scope that  suggests increasing  the solicited RS in order to configure the hosts reliably. Resilient RS has accomplished its goal within the scope of the problem statement

-          A suggestion was made to increase its scope which really steps into the scope/solution defined in draft-chakrabarti-nordmark-6man-efficient-nd and thus was objected by the co-authors of efficient-nd

-          A suggestion was made that all hosts should send periodic RS as an alternative to periodic RA – that does not work and several concerns were raised on taxing hosts with battery power


ND and battery power issue: [ aka need for such work?]


1)      Spontaneous all-hosts multicasts interfere with these mechanisms, thus the battery drain on the devices is much higher - especially in a typical network where the mobile devices move, and might trigger an RS/RA on each L2 roam between BSSIDs

2)      ARP in IPv4 had similar issues with broadcast, ND tried to solve that with directed multicast that depends on L2 technologies and works on fixed Ethernet. But both ARP broadcasts and ND multicasts are treated equally in many wireless environments where L2-drivers don’t support multicast resulting in huge signaling in the network and wasting battery power of the hosts[ mobile devices, internet of Things, wireless switches etc. ]

3)      Many wireless switches and wifi-controllers and AP mitigate the ND and ARP related flooding [ not all switches, AP implement MLD snooping] by providing proprietary solutions which result in vendor specific non-interoperable IPv6 solutions in the network else it prevents deployment of successful IPv6.


Summary of technical changes requested by the reviewers of efficient-nd:
Clarify problem statement with more justification of the issues with multicast and why registration is needed
 Clarify whether this draft will support draft-gont-6man-deprecate-eui64-based-addresses-00
 Draft refers to EUI-64 based IPv6-addresses and 64bit MAC address – Needs to fix this to state support for 48bit MAC address and non-EUI-64 based IPv6 address
 Clarify bootstrapping and DAD for link-local or not How to inform duplicate address detection during link-local address formation
 Clarify more on co-existence with the legacy model, distribution scheme of the addresses (hierarchical, hash-based, Š), nature of the registrars (Routers? Switches? DHCP servers? Š).
 Consider Mikael’s suggestion on using DHCPv6_IA_NA option to interact with a DHCPv6 server [ EAH interacting with a DHCPv6 server]
 Describe behavior /interaction with VRRP and how do we deal with single point of failure should there be single default router in the link
 Explain whether this draft really is limited to one central point bottleneck or it can handle single point of failure gracefully with multiple default routers
 Remove the use cases

Thanks,
-Samita

-