Re: 6MAN WG Adoption Call: draft-nordmark-6man-rs-refresh-01

[Erik Nordmark <[e-mail]>]

[Sorry for the duplicate - corrected the from address]

On 4/16/15 11:09 PM, Lorenzo Colitti wrote:
> On Sat, Mar 28, 2015 at 12:34 AM, Bob Hinden <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>           Title           : IPv6 Neighbor Discovery Optional Unicast
>     RS/RA Refresh
>             Authors         : Erik Nordmark
>                               Andrew Yourtchenko
>                               Suresh Krishnan
>
>
> I oppose adoption of the document as it stands.
>
> I believe that document cannot meet its stated goal of "allow the 
> operator to choose whether unicast RS refresh is more efficient than 
> periodic multicast RAs, while preserving the timely and scalable 
> reconfiguration capabilities that a periodic RA model provides" in the 
> presence of legacy hosts that do not support this specification.
>
> The reason is as follows: as noted in section 8.2, in the presence of 
> hosts that do not support this specification, routers must send 
> periodic Router Advertisements, otherwise the "timely and scalable 
> reconfiguration capabilities" cannot be maintained. This mode provides 
> no power savings over the status quo.
Lorenzo,

I think you must be making some unstated assumptions in coming to that 
conclusion, because it does not match my conclusion.

This specification allows a host to go to sleep and turn of its radio, 
which includes not being awoken by any multicast RA, and when it wakes 
up it can send a RS to refresh the information that might have changed 
while it was asleep. That provides power savings for that host.


>
> The document says that the network can operate in a mode where 
> multicast RAs are suppressed if it is known that all hosts on the link 
> support the specification. However:
>
>  1. It is impossible to know with certainty when a legacy node has
>     joined the network. If a legacy host's three initial Router
>     Solicitations are missed, then that host will never again send an
>     RA, and will never get IPv6 connectivity unless it disconnects and
>     reconnects. In contrast, today the node will get IPv6 connectivity
>     as soon as it receives a periodic RA.
>

As I pointed out in some earlier email, a host which is subject to 
packet loss so that the initial RAs are lost does not see any useful 
service. Your "as soon as" is currently as bad as 30 minutes (and 
separate discussions about MaxRtrAdvInterval might increase this to 6 
hours). I don't know which host will wait for that long. Thus I don't 
think you can claim that legacy hosts work under such packet loss 
conditions.

Regards,
     Erik

>  1. In general, it is impossible to know when a legacy node has
>     disconnected from the network. On some link layers this might be
>     possible by relying on layer 2 information (e.g., wifi association
>     state), but that requires that the router also be the layer 2
>     access point.
>  2. This mode provides no benefit unless *all* the nodes on the
>     network support the specification. Given that currently 0% of
>     nodes support it, it can be expected that the vast majority of
>     networks, where the operator does not tightly control the details
>     of the IPv6 implementations in the clients, will see no benefit.
>
>
> I would support adoption on condition that if the goal cannot be met, 
> we either abandon the work, or we qualify it with an applicability 
> statement that says that unicast RS refresh should only be used in 
> special-purpose networks where the operator controls both the devices 
> and the network.
>
> Also note: the above makes the document of limited use, but not 
> harmful. However, I think it's harmful, because it will cause 
> operators and device vendors who are familiar with IPv4 and its 
> client-initiated, pull configuration model (i.e., DHCP) to assume that 
> periodic RAs are not necessary, and therefore not implement them, 
> because things "will work" without them. I've been asked many times, 
> "Why do we have to listen to RAs anyway? Can't we just wake up and 
> refresh the information we need? That would be easier."
>
> Over time, relying on this mechanism will cause IPv6 to lose the 
> "timely and scalable reconfiguration capabilities" provided by 
> periodic RAs that we're trying to preserve, because the lack of those 
> capabilities will not cause visible problems. That model works today 
> in IPv4, but we should bear in mind that in IPv4 there are lots of 
> things that we're forced to do to do because we can't announce network 
> configuration updates to hosts in a timely manner. For example, we 
> have to use VRRP because it's impossible to change the default 
> gateway. Sometimes we use NAT because it's impossible to renumber. And 
> so on.
>
> Cheers,
> Lorenzo
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------