Re: rs-refresh

I'm generally for the the principle of using link-layer or network layer unicast and replication instead of multicast when replication is cheaper (and arguably it is going to be a lot of the time, because most link layers are actually replicating  frames over point-to-point links to emulate link-layer multicast anyway).

Multicast RAs could be link-layer unicast to individual nodes, once their known, as per RFC6085, so that could be used to reduce/avoid link-layer multicasts by periodic RAs. 

For more general multicast traffic, I came up with the following a while back (which I should revisit based on the discussion at the time I posted):

"MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6"
https://tools.ietf.org/html/draft-smith-mldv2-link-unicast-00

________________________________
From: Lorenzo Colitti <lorenzo@google.com>
To: Erik Nordmark <nordmark@acm.org> 
Cc: "6man@ietf.org" <6man@ietf.org> 
Sent: Thursday, 5 March 2015, 17:28
Subject: Re: rs-refresh

On Thu, Mar 5, 2015 at 2:37 PM, Erik Nordmark <nordmark@acm.org> wrote:

The idea is to provide an option where the network operator can move away from doing periodic multicast RA messages (on links like 3GPP/LTE, or WiFi where it is expensive) and instead have the routers instruct the hosts to send unicast RS messages to refresh the information - get a unicast RA.
>

I don't think this is as useful as it appears to be at first glance, for a few reasons:
    1. This is only useful if all the hosts on the link support it. If one host does not support it, then we fall back to sending multicast RAs again.

    2. Despite what the document says (in two different sections), it is not possible to make it so that "updated nodes can sleep better" AND "preserve the timely and scalable reconfiguration capabilities that a periodic RA model provides" unless there are no legacy hosts on the network
    3. If the router misses all the RSes from a legacy node (which for a legacy node that doesn't implement resilient RS, means a total of 3 packets sent within 3 seconds of each other, which is quite possible) then that node is blackholed.
    4. If the router loses state, all legacy nodes are blackholed.
In general I'd prefer to see what the problems with the RA push model are, and then address those, rather than going to a hybrid push/pull model like this.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------