Subject: Re: [v6ops] Reducing Multicast in IPv6 Neighbor Discovery

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 22 Feb 2014 18:03:35 +0000

Andrew,

Wanted to offer some comments on the draft.  Some of this may be a repeat
of text I recently send to Eric Vyncke in response to his draft.  We have
seen recently that flawed implementations either do not filter or
incorrectly trigger the use of solicited node multicast or Unicast
Solicited Router Advertisements which in turn result in either poor
battery performance and or high CPU utilization which in turn also impacts
the overall performance of the device.  RFCs that outline the proper
approach for processing and handling ND and RD messages are available and
generally when followed have a very positive impact on performance.  This
is specific to non mobile devices where battery life is less of a concern.
 I believe there is an opportunity to tune the network to further be more
friendly for power sensitive devices.  From our experiences we have tuned
and investigated a number of variables.  We currently leverage the L bit
to try and minimize how LL IPv6 MC messages are transmitted in cable
broadband networks.  Truthfully we had to require that many of
implementations allow the setting of the L bit for connected prefixes.
Early implementations did not allows this which resulted in us not
deploying these solutions until they became compliant with our
requirements.

More recently recently we investigated neighbor table lifetimes to
minimize router originated ND messaging.  As the draft states, in large
deployments where there are thousands of nodes this quickly becomes
interesting and results in a high rate of LL ND messages that all nodes
have the opportunity to see and perhaps incorrectly process.

For our WiFi work the use of stateful DHCPv6 exclusively is simply not an
option today and may never be largely because not all nodes uniformly
support DHCPv6.  As such operators who wish to bring IPv6 to the largest
population of devices require that several addressing and configuration
mechanisms be enabled simultaneously.  In our case SLAAC + RNDSS +
stateless DHCPv6 will be leveraged for our WiFi deployment.

Thanks,

John
=========================================
John Jason Brzozowski
Comcast Cable
m) 609-377-6594
o) 484-962-0060
w) www.comcast6.net
e) [email-masked]
=========================================

-----Original Message-----
From: Andrew Yourtchenko <[email-masked]>
Date: Tuesday, February 18, 2014 2:57 PM
To: v6ops <[email-masked]>
Subject: [v6ops] Reducing Multicast in IPv6 Neighbor Discovery

>Following Eric Vyncke's mail, if you got interested by
>that draft, you may find this draft interesting too:
>
>http://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-0
>0
>
>discusses some practical measures that can be taken "as is" to make IPv6
>and WiFi better friends.
>
><background>
>
>If someone happened to be at this year's FOSDEM or my employer's
>conference, CiscoLive, the WiFi networks there ran most of the things
>specified in section 4.
>
>(for some background info, here's some stats from the ciscolive network:
>http://2014.ciscolive-ipv6.com/munin/ipv6noc/ipv6noc/index.html; FOSDEM
>was about the same ballpark number of hosts).
>
></background>
>
>--a
>
>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 22 Feb 2014 18:15:52 +0000

Forgot to mention, that in home scenarios we need to make sure that we do
not make inaccurate assumptions around interval settings i.e. lengthening
router advertisement intervals .  In many cases these are set as such to
ensure a proper customer experience.

John