Re: rs-refresh

On 3/5/15 12:11 AM, Mark ZZZ Smith wrote:
> 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.

Mark,

If we want to enable hosts to sleep, how do you see the router being 
able to schedule when those multicasts-as-unicast will be sent to a 
particular unicast link-layer address? It would seem like that needs to 
be when the host is awake.
>
> 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

That approach would be interesting when the number of members in the 
group are small (and there is no MLD snooping); when the average number 
of members in a group on a link are near one it would perform very well.
But using it for RAs send to all-nodes seems less obvious from a 
performance perspective.

Thanks,
    Erik

>
>
>
>
> ________________________________
> 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
> --------------------------------------------------------------------
>