Re: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-mpl-parameter-configuration-06: (with COMMENT)

[Yusuke DOI <[e-mail]>]

Hi Stephen,

Thank you very much for the review.

On 2015-07-08 17:04, Stephen Farrell wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> - I don't get the update model - if all MPL forwarders have
> to use the same parameters but they don't all do DHCPv6 at
> the same time, then won't new parameter settings take a
> while to propagate to most of the network? And won't that
> cause a problem? Don't you need a "start using this set of
> parameters in N seconds" field in the dhcp option to handle
> that? This is not a DISCUSS as I think it relats to Barry's
> so please try address this when addressing that.

I believe your question is beyond Barry's DISCUSS. Let me clarify it here.

In general, all MPL Forwarders should have identical parameters to make 
a better load balance. However, the parameter synchronization is 'better 
to have' and even if there are mismatched parameter set it does not 
break interoperability or operation. Some forwarders would do more 
retransmission than others if the parameter is not identical. I consider 
this is acceptable behavior for MPL. To ease the unbalanced 
retransmission, I added some text to limit parameter update ratio per 
information refresh time.

For join and leave on forwarders, some node may not be able to receive 
messages during transitive period (not all forwarders have joined). 
However, adding some delay on the configuration will not ease the case. 
It's up to application to send a multicast message after all nodes have 
acquired the newest configuration, or to send a message during 
constructing MPL domain if the message is good even for delivered to a 
fraction of nodes.

> - please do not pretend rfc 3315 is a solution for anything
> unless you mean it and I don't think you do. 3315 is I think
> the canonical example for mythical security:-(

To be honest, my situation is to go without DHCPv6 security and expects 
network-level security. We do strict node admission using RFC5191 and 
assumes no untrusted node in a network.

I'm wondering how would I describe security consideration beyond my 
situation in the document, without relying on 3315. I appreciate if you 
give me some suggestion on this topic.

Thanks,

Yusuke